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?

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.

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

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

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

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.

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.

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.

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)?

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.

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.

Is this a candidate for closure?

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

Close

Closed per WG