Making OAuth Work on the Open Web

From IIW
Revision as of 06:58, 31 October 2018 by Iiwnotes (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Making Oauth Work on the Open Web (Share & Tear)


Day/Session:Wednesday 5H

Convener:Aaron Parecki

Notes-taker(s): (1) Aaron Parecki & (2) Tom Brown


Tags for the session – technology discussed/ideas considered:

oauth


Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

(1) Links to Aaron’s slides and files from session:

web link: https://speakerdeck.com/aaronpk/making-oauth-work-on-the-open-web

PDF: https://slides.aaronparecki.com/2018/making-oauth-work-on-the-open-web.pdf

Here are the links mentioned within the slides:

https://indieauth.net/

https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web

https://www.w3.org/TR/indieauth/

https://hacks.mozilla.org/2018/10/dweb-identity-for-the-decentralized-web-with-indieauth/


(2) Tom Brown’s Notes:

Session is related to article:

https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web

Discussion:

OAuth for the open web does not require client preregistration nor locked down user accounts. Instead, there is IdP discovery and bring your own identity.

OpenID Connect does not solve these original problems of OpenID

There can be any number of authz servers so it is impractial for devs to do client registration for all. For instance, Mastodon adoption has this problem because devs can't easily register on every instance.

UserIDs need to have a shared global namespace.

There is no overlap between Google and Microsoft user namespace, for instance.

Limit the problem space:

Client ids and user ids are full urls (provides path for discovery)

OpenID usability problem was with the way the url was presented to user, not the url itself.

The browser now autofills url and an email address can resolve to a url. Start with something that can turn into a url.

IndieAuth is just an extension to OAuth 2

Focus on the client:

client_id in the redirection url is the url of the appropriate

App info is published at the url that is the client_id. It seems choosing one of these three possibilities would be ideal:

1. parse HTML for microformats (downside is that server needs a microformats parser)

2. manifest.json

3. .well-known

(an example client is https://quill.p3k.io/)

Let's consider beyond the Indieweb and include the open web which does not seem to include enterprise.

Justin R. references Kitties are Fluffy!

Book ref: Why We Fail https://rosenfeldmedia.com/books/why-we-fail/

a traditional IdP often doesn't want to allow arbitrary clients that haven't registered first

SPs often want more than a subject

https://indieweb.org/authorization-endpoint


W5H.jpg