WEB AUTHN Together with DID’s

WebAuthN Together with DIDs

Tuesday 4M

Convener: Christian Lundkvist

Notes-taker(s): Christian Lundkvist

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

We discussed a basic overview of the webauthn protocol and also a basic overview of DIDs, DID documents and the Universal Resolver.

We noted that the authors of the Webauthn protocol has decided that account recovery is out of scope. This means that the protocol does not handle the case where I lost my authenticator device and need to associate a new authenticator device with my account at a relying party.

We discussed using a DID-based authentication protocol for the account recovery. There were questions about if the webauthn protocol is flexible enough to support this. It turns out that the webauthn data payload has a field “user_id” or similar that can be used for a string, and here we could put the users DID. Thus it seems possible.

Since recovery is out of scope for the webauthn protocol it means that there is no need for a website implementing an authentication protocol to have to choose between webauthn or DID Auth. It would also be the case that we can avoid a political fight where a DID-based authn protocol is attempting to replace webauthn. Any relying party can implement a webauthn protocol and still experiment with versions of DID Auth in their account recovery, unrelated to the core protocol.

We discussed privacy concerns: if you supply the same DID to the “user_id” field for all the websites you sign up to then you can be immediately correlated between sites and you would then lose the benefit that the webauthn protocol will generate a new public key for each website. This could be mitigated by using a Sovrin-style pairwise DID or otherwise using different DIDs for different classes of websites.