Propose extension: Delegation of Authentication

[bvandersloot]

It is unclear to me where this should be submitted. I see that there is a proposed registry for extensions, but it seems not yet formed. Please direct me to the right place to submit this if this is not the place.

WebAuthn has potential authentication use-cases not discussed or supported by the current model. Optional support of these use cases up front can prevent barriers to adoption from parties concerned with them. In particular I am considering the following:

• A User grants access to their account to a trusted party that is not in the same room as them.
• A User maintains backup tokens to every RP, without having to register a second Authenticator to every RP.
• A Client maintains SSO for all RP that functions across client devices for a single Authenticator.

Disclaimer: I am not a cryptographer, so one should look at this. But there isn’t anything too exotic here.

The rough cut is as follows: when a client is registering a new key with the server, it also has the key sign a value that is HMAC(restrictions, secretKey). The HMAC and restrictions are shipped off for the server to hold onto. Now anyone that can prove ownership of secretKey within the restrictions can register a new key with that account. For now these restrictions are how long the token should last, how many uses it gets, and what public keys work with it.

Put even more roughly, this is a tool to create trusted tokens that exist off of the Authenticator, bootstrapping trust from registration.

A draft of the extension is available here.

[emlun]

It's not clear to me what part of this cannot already be done using a plain authentication ceremony with a challenge containing the HMAC. Care to elaborate on that?

[bvandersloot]

The challenge is created by the RP, so in that case the RP has the new secret key. The scheme I describe lets the Client generate the HMAC (and own the new secret key).

The idea here is that there is a second secret value possessed by the Client which need not be associated with a specific Authenticator, all while only completing a single ceremony.

[emlun]

The way I understand your linked draft, the secret is sent in plaintext to the RP in the "use" action. Isn't it?

[bvandersloot]

Correct. I had considered a zero knowledge version as well, based on Schnorr signatures, but that is not reflected in the linked draft.

[emlun]

In that case, what is the point of the client "owning" the secret key?

[bvandersloot]

The client can then share it with another trusted party out of band, allowing them access. This can give emergency access to a trusted friend or an account recovery agent.

[emlun]

I fail to see how that is fundamentally different from a traditional password, if the whole thing relies on a single secret shared between all participants.

[bvandersloot]

It is fundamentally different as it can be constrained in the ways it can be used, e.g. number of uses, be bound to a public key, or only be valid for a certain amount of time. Also, it is more similar to a recovery phrase, since it is only used to register a new key to the account.

[emlun]

Still, isn't all of that constraint logic internal to the server? How is it different from, say, an OAuth token (which, like a password, is also a shared secret)?

[bvandersloot]

This is a good point. Perhaps having knowledge of an OAuth RP being run by the same party would be a more modular solution. I was thinking only inside of this protocol to try to enable more use cases with an extension.

[emlun]

Yeah, WebAuthn currently is just an authentication mechanism that stipulates as little as possible about how the mechanism should be used. Authorization and other security concerns are separate from the authentication mechanism itself, and I think it's best to keep WebAuthn focused on that.

[equalsJeffH]

Is this a candidate for closure?

[emlun]

I would say yes, but I can't speak for @bvandersloot or the rest of the WG. :)

[ve7jtb]

Close

[nadalin]

Closed per WG