Authentication-only proposal - AcctAuthn

[pierogitus]

Thanks for putting together a great resource on the problem space. I’d like to take a step back and broaden the solution space. Looking back at the history of OpenID and OAuth, they had aspirations of ubiquity but ended up trending towards enterprise use cases and grew in complexity accordingly. Mozilla persona had more of a consumer focus but I think tried to be too novel and likewise got tripped up by complexity.

There seems to be a conventional wisdom that RPs want/need profile data/authorization but I feel this theory is mostly untested because developers have never been given a good low-complexity authentication-only option to experiment with. So I’m proposing a solution that returns to the goal of eliminating passwords without trying to solve every identity use case imaginable.

Implementation and UX

1. User visits example.com and inputs bob@example.net to a sign up/login field.
2. example.com may interpret that string like an account in RFC7565 or WebFinger. example.com performs a fetch with credentials to https://example.net/.well-known/acctauthn/?acct=bob%40example.net&nonce=knswprfcmqzxxxxxxxxxxxxxx
3. The user agent recognizes this precise well known URL structure and adjusts the fetch mode to omit the origin header.
4. example.net responds based on request credentials (response format TBD). Response headers include Access-Control-Allow-Credentials: true and Access-Control-Allow-Origin: * The IdP could have a real-time approval feature that uses the nonce to help identify the request.
5. In this special fetch mode the user agent accepts the above header combination and allows example.com to read the response. If response was unsuccessful example.com may instruct the user to login to example.net or fallback to treating bob@example.net as an email and proceed with traditional login flows.

Analysis

• The classification problem is handled because the well known URL allows the browser and IdP to narrowly opt in to the special fetch behavior.
• RP origin is hidden from IdP. The IdP would have timestamps of requests but would need RP collusion to correlate.
• Directed identifiers are not achieved within the protocol itself but this goal appears mutually exclusive with RP hiding. If we can only have one, RP hiding seems the better choice since:
  • Many scenarios will give linkable info anyway (phone, shipping addr)
  • Directed identifiers can be achieved out of band with IdP issuing multiple ids and username managers similar to current password managers.
• Reusing the syntax of an email address helps adoption.
  • Since the mailto: scheme is rarely used in UIs it fits with users current understanding of an account at a domain and doesn’t try to introduce a new concept like logging in with a URL.
  • Easier for IdPs that are email providers to communicate the new capability.
  • Easier for RPs to build a coherent login flow that optionally uses federation.
  • Enables IdPs that are not email providers to help bootstrap the protocol.
  • The above points underpin a belief that RPs will be able to build an experience with no redirects/popups/iframes and that improvement will overcome resistance to broad adoption of federation.
• The protocol can be deployed without browser support. Requests would follow normal CORS rules and expose the origin. No worse than current OAuth. Browser support would just be privacy enhancement.
• Service discovery or redirection of the IdP URL was left out of the example steps for conciseness. While WebFinger comes to mind as a discovery mechanism, it's desirable to have a narrow URL space to apply the new fetch mode, so discovery should probably be protocol specific within the same well known URL.
• Creating a new name for broad federation is hard. Fortunately this protocol would mostly be transparent to the user so shouldn’t require a catchy user friendly name that is equally vague and confusing. AcctAuthn is descriptive of the mechanism and the relation to RFC7565 and a highly unique string making it search engine friendly for developers.

[samuelgoto]

There seems to be a conventional wisdom that RPs want/need profile data/authorization but I feel this theory is mostly untested because developers have never been given a good low-complexity authentication-only option to experiment with.

I think this is a reasonable thread to pull from.

Directed identifiers are not achieved within the protocol itself but this goal appears mutually exclusive with RP hiding.

Can you expand on this? I've been converging towards a similar conclusion (that they are mutually exclusive -- not that RP hiding is more important than directed identifiers), but could use another person articulating with their own words why these are mutually exclusive.

Directed identifiers are not achieved within the protocol itself but this goal appears mutually exclusive with RP hiding. If we can only have one, RP hiding seems the better choice since: Many scenarios will give linkable info anyway (phone, shipping addr)

These can be tightened up right (e.g. warnings during autofill?)?

Directed identifiers can be achieved out of band with IdP issuing multiple ids and username managers similar to current password managers.

Can you expand on this?

The protocol can be deployed without browser support.

I'm wondering: if it can be implemented without browser support, why hasn't it? importantly, if it doesn't need browser support then there isn't anything concrete that browser engines need to act on?

[pierogitus]

Directed identifiers are not achieved within the protocol itself but this goal appears mutually exclusive with RP hiding.

Directed identifiers are really just a mapping so the mapping has to be stored somewhere. The only places in our model are:

• With the IdP - convenient but the RP must be leaked to retrieve the correct id
• With the RP - doesn't work because it would need authentication to be retrieved
• In a third party - less convenient but the most private and flexible since the browser can be the third party.

I should also clarify I didn't mean RP hiding is more important across the board. Its a matter of taste whether you trust the IdP or RP more. If we can't seamlessly have both there should be solutions that cater to each taste.

These can be tightened up right (e.g. warnings during autofill?)?

Not sure what you mean by tightened but I was thinking of e-commerce sites where linkable info is required to buy something so privacy of the user id doesn't really help.

Directed identifiers can be achieved out of band with IdP issuing multiple ids and username managers similar to current password managers

So if you think about non-federated password login, if you use the same username on every site, you would need a unique enough string that it becomes a linkable piece of info. Browser autofill can already help you mitigate this because it stores the username for each origin. So in effect you can manually create directed identifiers. In this protocol, browser autofill or password managers would manage that mapping in the same way except the IdP would create the usernames like a7d43cc569b5b@example.net Also the browser/manager has less attack surface since there's no password to store.

I'm wondering: if it can be implemented without browser support, why hasn't it? importantly, if it doesn't need browser support then there isn't anything concrete that browser engines need to act on?

Browser support is needed for RP hiding but not for authentication to function. As for why this hasn't been tried my best guess is that its cultural rather than technical. Every identity solution that comes along tries to be the ultimate solution. Here's an interesting take from one of the early authors of oauth. That has created a large gap in the solution space. Since its evident there are mutually exclusive trade-offs involved I think a more diverse family of solutions is needed.

[gffletch]

Full disclosure: I'm a community elected board member of the OpenID Foundation.

My concern with having disparate point solutions (i.e. solutions that are simple but only solve a few use cases) is that it forces both IDPs and RP to implement multiple solutions and then manage them. Both code complexity and deployment complexity increase.

It is possible today to use OpenID Connect for just authentication (no need for authorization) as well as then extend your implementation to add authorization when it becomes needed. I'm definitely curious if there are implementation issues with OpenID Connect that prevent RPs from adopting it.

That said, if RP hiding is a key goal then OpenID Connect isn't the best protocol. For that I would use one of the self-sovereign-identity flows where the browser can directly push verifiable credentials (as released by the user under user consent) to the RP. The RP then uses the verifiable credentials to create an identity for the user. After that just proof of the directed identifier is sufficient to identify the user and that proof can be issued by the browser directly to the RP. Basically, the browser becomes an SSI "wallet" for the user. Both verifiable credentials and directed identifiers (DID) are defined in (draft) specs from the W3C.

[pierogitus]

Yes crowding the landscape is certainly a headwind for any solution but as far as I can tell OIDC doesn't seem poised to eliminate passwords web wide (for reasons like the NASCAR problem) so looking for ideas outside that stack seems inevitable. I think there's a large enough market that doesn't care about upgrading to authz but its hard to measure because that market has never been served.

DIDs and WebAuthn have promising features too but they're not fully comprehensive either so I think that also points to practical implementations being a mix of solutions.

[achimschloss]

Some remarks:

It is possible today to use OpenID Connect for just authentication (no need for authorization) as well as then extend your implementation to add authorization when it becomes needed. I'm definitely curious if there are implementation issues with OpenID Connect that prevent RPs from adopting it.

Fully agree with @gffletch - the lowest level (in terms of data sharing) of entry that still constitutes a login would be to only pass a pseudonymous id as a result of the authentication. This is perfectly fine with OpenID Connect by just starting the auth flow with ../authorize?scope=openid no additional scopes, no claims parameter. The ID Token would only contain the sub as a user identifier, in case it is pairwise this is a directed identifier - see Subject Identifier Types

That said, if RP hiding is a key goal then OpenID Connect isn't the best protocol

DIDs and WebAuthn have promising features too but they're not fully comprehensive either so I think that also points to practical implementations being a mix of solutions.

Completely hiding the RP is not compatible with the Idea of an IDP for various reasons, that has been discussed in a few tickets already. This does not change with DIDs btw. unless you expect that users will at scale register DIDs and maintain their own wallets (private keys) without the support of a service provider (which in case would become an IDP again).

WebAuthn is perfectly compatible with IDPs, but as said the lowest level that constitutes a login would be a pseudonymous ID as a result. WebAuth does not help with that, you still need a user ID when using WebAuthn (i.e. user will need to register to leverage it) Try for yourself with https://webauthn.io/

The aim of this proposal to my understanding is to define an explicit integration with at scale IDPs and not to start registering users from scratch with other methods. Of course there can be other types of implementations to maintain an Identity in-browser, but that has shortcomings of its own and does not seem in scope here.

[pierogitus]

Completely hiding the RP is not compatible with the Idea of an IDP

That's exactly the kind of thinking I want to poke at. Who decided that's the way an IdP has to be? Who does that benefit and who does it leave under-served?

[achimschloss]

I can only recommend to read the comments on this in the other issues where some items why this is the case have been touched upon and deep dive into the respective protocols and why they are build the way they are. There is extensive functional and security related documentation on OpenID and the underlaying OAuth protocols for example.

You can for sure write some sort of browser plugin to sign in users on different sites with the same account based on WebAuthn, its just limited in functionality then (platform independence, portability, privacy controls etc.) more or less like a password manager plugin.

[samuelgoto]

I think the closest that would satisfy this thread right now is the delegation-oriented variation described here.

There seems to be a conventional wisdom that RPs want/need profile data/authorization but I feel this theory is mostly untested because developers have never been given a good low-complexity authentication-only option to experiment with.j

I think this is the most important observation and one that we arrived at independently too using slightly different terms.

Mozilla persona had more of a consumer focus but I think tried to be too novel and likewise got tripped up by complexity.

I think Mozilla got tripped up by demand, not complexity. And I believe that demand has changed since then.

[pierogitus]

Thanks for circling back. I agree there's interesting possibilities in adding another entity to the mix but I guess that brings up the question what is that entity's business model and how does it make its way into the ecosystem.