WeChat ID
aaronpk_tv
-
at Best BuyPortland, Oregon • Thu, November 22, 2018 5:14pmYep it's pretty crowded -
UPS Customer Support
https://twitter.com/UPSHelp
•
Nov 22
Thank you for reaching out to us. Please, DM the details of your concern. Include your tracking and phone number. Please include your shipping address. ^LG
sometimes people say nice things about you on twitter too -
Getting on the Fediverse with your own site using Drupal and Bridgy Fed just became easy! https://realize.be/blog/your-site-fediverse-bridgy-fed #drupal #fediverse #indieweb
-
Loving the potential of IndieAuth!
https://www.oauth.com/oauth2-servers/indieauth/authorization/
Going to implement a personal endpoint to learn it. (I'll take notes, blog and share the source.) -
On Wed, Nov 7, 2018 at 7:20 AM Joseph Heenan <joseph at authlete.com> wrote:
> It may be worth slightly rewording 7.2 as it may encourage a growing misconception that all native apps must be public clients. With many devices now having embedded HSMs, we’ve seen increasing interest in mobile apps being dynamically (per-install) registered oauth2 private clients, and that model has a lot of advantages. (I’m not sure if we might see a similar model evolving for web apps.)
That's a great point, thanks. I've removed the reference to native apps being public clients since it doesn't really add anything to this spec if I have to caveat the description.
On Thu, Nov 15, 2018 at 12:58 PM Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
> > > First of all the AS decides whether it issues refresh tokens or not. Having the ability does not mean the AS must do it. If you feel it’s safer to not do it. Fine.
> > Sure, and this should be mentioned then somewhere (either in the threats doc or in this proposed best practice doc). Not all end developers using these protocols fully understand the ramifications.
> @Aaron: I suggest this goes to the SPA BCP since this is client specific.
Thanks, I agree that this document should include some recommendations around refresh token handling. Looking at the discussion in this thread, it seems there are a few different strategies folks are taking. Since it seems like there isn't a strong consensus, it sounds like this would be better suited for the "Security Considerations" section, and to not make MUST/SHOULD recommendations, but rather just point out the issues. Any thoughts on that before I take a stab at writing something?
I've incorporated some of the other feedback here and published an updated version:
https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-01
Thanks for the feedback so far. -
A great resource to know more about decentralized web: https://indieweb.org/
Don't forget to have fun, your website is a playground!!
Let's share what we know, just chose where you want to share it.
#vdthess18 -
In case you were wondering what I will be doing the 4 or 5 days a month that I am home in between travel ➡️ https://twitter.com/anomalily/status/1064377654600589313 #BuffyPreboot
-
Okay, in honor of the possible #buffyreboot we are calling this occasional series of watching Buffy 21 years later #BuffyPreboot - follow for commentary on how computers have aged in Buffy. Also tweeting everytime a cell phone could’ve prevented a death.
-
I just added the ability to add audience to my posts. For public posts It adds a small description at the top of the post defining who the audience of the post is. For example, I have a reply I wrote for an online class. In the future, it will control who can see a private post.
-
This is a good tweet series. My only complaint would be that it needs a hashtag so that I can find them all immediately. 😆
-
Had to do some surgery on #BarBot today since the SD card in the raspberry pi finally failed. Two years isn't a bad run for a card tho!
