I'll add just one more thing here, even if the protocol exists, the clarity, and was supported, I'm not sure that it would even be that widely used. Thinking about this from the user perspective, I just can't imagine how many would really choose to even need or want to set up these other mechanisms. There is a very small community dedicated to web3.0 which supports browser extensions to log in to various tools via crypto blockchains.
There's still only a handful, and identity providers, who are actually in this WG, can attest to supporting N+ number of AS and WebAuthN, and username/password, and likely anything else users want. As one of them, we add anything and everything that application developers want to support. So it isn't the lack of paradigms, RFCs, or general neglect (/lack of desire) to implement these. The blocking factor is the symbiotic evolution of user desires, platform capabilities, and AS features. So as all AS don't support all features, and as it seems the capabilities are there, even if they were supported by user facing applications, there is still further that the community as a whole needs to go to adopt the mindset of wanting to bring custom unverified AS to the table.
On Wed, Feb 24, 2021 at 5:34 PM Tim Bray <tbray@xxxxxxxxxxxxxx> wrote:
The OAuth work has successfully built a perfectly reasonable syntax and protocol for exchanging identity and attribute assertions, and that's fine. What it hasn't done is opened up the world of Identity Provision, but that's not a technical problem.OAuth flowed out of OpenID back in the day. The core idea of OpenID, beginning with the attractive but wrong notion that URIs are a good way for people to identify themselves, was that service providers should be prepared to trust arbitrary identity providers. At the moment, nobody has figured out an automated way for services to figure out which identity providers they want to trust. The counter-argument is that service providers should just trust people to pick appropriate identity providers, and it has never in my experience succeeded in convincing a single lawyer or business-policy type.On Wed, Feb 24, 2021 at 7:21 AM Justin Richer <jricher@xxxxxxx> wrote:I agree that the NxM problem is the purview of the whole IETF, but it’s something that we’re particularly interested in over in GNAP. As the editor of OAuth’s dynamic registration extension and the GNAP core protocol, I hope I can add to this conversation.From a technical standpoint, OAuth’s dynamic client registration lets arbitrary clients talk to an AS, but the trust isn’t there in practice. On top of that I think this problem is exacerbated by a fundamental protocol design element of OAuth: the client_id that’s required. That field means there’s an assumption that a relationship was set up between the pieces of software, implied to be trusted by admins at the AS. Sure you can get that client_id under special circumstances, but there’s still a special weight handed to that and the dynamic stuff feels like you’re giving up control as an AS. In GNAP, the relationship is inverted, and it’s designed as “dynamic-first”, with pre-registered clients being an optimization on top of that.Does this solve the NxM problem? No, because companies are still going to decide that they only talk to keys or identifiers that they know ahead of time. But the protocol puts the dynamic case forward as baseline and fits in much better with the likes of JMAP than OAuth ever could:- {The Bat} creates a key pair.- {User} enters their email address into {Bat}, {Bat} does discovery (maybe that’s a JMAP thing? Webfinger?) and finds the JMAP server and the GNAP endpoint for authentication as an option.- {Bat} talks to the GNAP AS at {ISP} and presents the key it just made up. {ISP} has never seen this key, but knows how to talk GNAP and get the user to authorize {Bat} to access email.- {User} does this using GNAP and gets back an access token that’s tied to the key {Bat} made back at the beginning. That token is tied (at the {ISP}) to the user’s account.Yes, you can do all of this today with OAuth (and people have done so), but OAuth’s basic model of “go do discovery and registration first and THEN talk to me” is a trust impediment more than it is a technical impediment. The “negotiation” part of the GNAP name comes from the philosophy of “start talking first and figure out what you need as you go”. Instead of jumping through hoops to get something you can trust, you just start in and then decide how much you trust it. A corporate rollout could use its own key distribution mechanism and static registration to limit which client instances talk back to the company server, regardless of which accounts would authorize access on top of that. An internet-facing service is going to be more likely to take a TLS approach, of “I’ll talk to you in a secure fashion without caring who you are right now”.We really are trying to make GNAP a consistent protocol at its core and learn from problems with OAuth in the wild, all while letting GNAP address a wider variety of use cases. I agree that GNAP could be clearer about specific use cases, and we’re working on the spec still so any help here is appreciated.— JustinOn Feb 24, 2021, at 7:15 AM, Bron Gondwana <brong@xxxxxxxxxxxxxxxx> wrote:On Wed, Feb 24, 2021, at 23:09, Warren Parad wrote:(I tend to trend lightly in the pronoun area, mostly because I'm shocked that openid included gender but not pronouns)I hadn't heard that to be called the NxM problem, so that definitely cleared up the potential confusion (at least for me).I think GNAPs lack of clarity is a non sequitur for the handling or not of the multitrust arbitrary-client with arbitrary-service, however it's lack of clarity for me prevents me from knowing whether GNAP actually seeks to solve this problem. So from an OAuth WG perspective we can still ask:Is this or should this problem be left to GNAP to solve, or is an OAuth WG responsibility?Honestly I think the problem space is the whole ietf's responsibility. Protocols that allow an end user to safely transfer data between two parties that don't have a pre-existing trust relationship are a key part of enabling user freedom and user choice.Bron.
OAuth mailing list
OAuth@xxxxxxxx
https://www.ietf.org/mailman/listinfo/oauth
