Aaron Parecki

omg yesss! HWC re:invent!

Viewsonic actually! One of the last non-smart TVs, so I'm glad it isn't actually broken!

on the train

I did it. I found a TV and survived the crowds and carried the TV back to the MAX station.

Shoulda brought my cargo bike. That's a long way to carry a TV box if this works

sometimes people say nice things about you on twitter too

That does look nice! I hadn't heard of it before. I just downloaded it and went through the tutorial, not bad! I'll try to use it for my next project.

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.

yesss i want to know how this goes

Pulling out of the gate to the runway front first and taking off with no wait feels way more like riding in a car that can fly than an airplane

looked up MIDI versions of as many Beatles songs as I could find

Since Mastodon already supports OAuth 2, and all users already have a URL, adding IndieAuth to Mastodon would not be a huge leap.

I'm pretty excited about the wireless charging! Not super thrilled about FaceID, since I thought TouchID was working just fine. I hear good things about the camera compared to the 6S too, so that should be fun!

I started working on a little proxy tool to do exactly that. It's just an API right now, but it lets you delegate all the activitypub stuff to an external service while still using your domain name as the identity. https://github.com/aaronpk/Nautilus

Thanks Hannes,

Since I wasn't able to give an intro during the meeting today, I'd like to share a little more context about this here as well.

At the Internet Identity Workshop in Mountain View last week, I led a session to collect feedback on recommendations for OAuth for browser based apps. During the session, we came up with a list of several points based on the collective experience of the attendees. I then tried to address all those points in this draft.

The goal of this is not to specify any new behavior, but rather to limit the possibilities that the existing OAuth specs provide, to ensure a secure implementation in browser based apps.

Thanks in advance for your review and feedback!

Yeah I'll be at Accessibility Club!

TIL my last name means sausages in Slovak

Yep outsourcing is fine as long as you have a way to migrate to another provider! If we didn't hold that principle, it's a slippery slope to start saying everyone should host their site from a server in their house, and from there to having to build their own hardware. Gotta draw a line somewhere, and ours is identity and data portability.

Yes, that's the idea in fact. Re: GDPR, there's plenty about that you can read here https://www.okta.com/gdpr/

But on the IndieWeb front, it's totally fine to outsource various parts of your website, as long as you own your online identity. That's why using a web host like micro.blog is still in line with IndieWeb principles as long as you point your domain to it.

Using Okta to handle logging in to your own site is just outsourcing the internal user account management. There are some things I would rather have an expert do well for me rather than doing a poor job of it myself.