Hey Bron, (caveat: I only skimmed the other conversation)
I'm trying to figure out how best to digest your message. I feel like I'm missing context in your message, is there something about JMAP required authentication that you're asking to be considered in OAuth. Help me figure out what I'm missing. - Warren Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Tue, Feb 23, 2021 at 2:03 PM Bron Gondwana <[email protected]> wrote: > (bringing this back to just the OAuth list) > > On Tue, Feb 23, 2021, at 23:46, Hannes Tschofenig wrote: > > I don’t know whether it is already too late for your document (which is > dated 2016) to consider the use of OAuth but Rifaat and I are happy to put > you on the spot in one of our future virtual office hours or virtual > interim meetings. > > > It's never "too late" - we could add a "how to Authenticate JMAP using > OAuth" document easily enough. > > That specific document which I mentioned went through many revisions and a > split to eventually become RFC8620 and RFC8621. The core JMAP spec says > this about Authentication: > > 8.2 <https://tools.ietf.org/html/rfc8620#section-8.2>. Authentication Scheme > > > A number of HTTP authentication schemes have been standardised (see > <https://www.iana.org/assignments/http-authschemes/>). Servers > should take care to assess the security characteristics of different > schemes in relation to their needs when deciding what to implement. > > Use of the Basic authentication scheme is NOT RECOMMENDED. Services > that choose to use it are strongly recommended to require generation > of a unique "app password" via some external mechanism for each > client they wish to connect. This allows connections from different > devices to be differentiated by the server and access to be > individually revoked. > > > What it doesn't have is something like what existed in the first draft, > which allowed out-of-band authentication in many ways, and *probably did > require security review - but security review from people who wanted it to > succeed rather than from people who wanted it to go away because it wasn't > OAuth*. At the time, that didn't sound like something achievable. We > were told that any authentication proposal would have to get past the OAuth > working group, who would shoot it down or stagnate it for years. Maybe > that was wrong, but it was the impression we got from multiple people in > multiple conversations, both in our working group and in the hallway track. > > The original authentication protocol started with a username and a > service, and got back a session token plus list of authentication methods > that were allowed, or even a "we already authenticated you out of band - go > right ahead". > > The methods included password or password plus second factor, but also > allowed for things like "here's a URL, go sign in there and when you're > finished your session will be valid" or "a popup has been shown in your > existing sessions on other clients, confirm this code and click OK". > > The important thing was that there was no requirement that there be any > web context built into the client - it could happily just sit there waiting > for a push event down the push channel to tell it that the session had been > authorised, or poll to see if it was allowed access yet. The > authentication could be entirely out of band after the initial handshake. > > It's a quite different model than OAuth2. It's probably closer to GNAP, > which is why I've been watching that with interest, though not with enough > time to engage closely. > > Cheers, > > Bron. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > [email protected] > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
