Website Authentication

[TelegramSam]

Authenticating to a website in an SSI way is a common request. This issue details options for accomplishing that goal.

OpenID OIDC is a popular option that allows the transfer of credentials as part of the process. For those already involving OpenID, this seems like a good option. For those that are not, this seems like a heavy option.

I think that we can propose a simple alternative using Out Of Band Messages presented as QR codes. I've identified three paths that this could take:

• Presentation of a non-identifying credential, which operates like a capability.
• Presentation of an identifying credential, likely issued by the same website. Will contain an ID. Could also be an email access credential.
• Proof of DID control. This can be done by sending any DIDComm message.

The first two methods can use existing credential exchange protocols.
The last method could be accomplished via a Trust Ping, the message id (thread_id of the ping response) serving as a nonce.

The website itself can function as a minimal agent at the low end, or use a separate agent to engage the protocols.

Questions:

• What are the holes in this plan?
• What details have I missed describing?
• Is this an invalid use of trust ping? Should a protocol dedicated to the purpose be created?
• Is this going to be a good solution for website auth?

[swcurran]

Wondering why the last method needs anything other than OOB and DIDExchange. If it is the first visit to the site, a new exchange of DIDs is performed and proof of control is exhibited. If this is a subsequent visit, a "reuse" is completed (which is just OOB, so there is no DID-Exchange needed), which exhibits proof of control. Is anything else needed?

[TelegramSam]

I've been convinced that using trust ping is the wrong answer, for semantic reasons. The same goes for not including any message.

The user scanning the code needs to be prompted, on their mobile agent, in a meaningful way. Having a specific protocol for website authentication will make the semantic meaning clear, and make it easy to present a good user interface for user authorization.

Maybe the WebsiteAuthentication Protocol?

[llorllale]

@swcurran

Wondering why the last method needs anything other than OOB and DIDExchange. If it is the first visit to the site, a new exchange of DIDs is performed and proof of control is exhibited. If this is a subsequent visit, a "reuse" is completed (which is just OOB, so there is no DID-Exchange needed), which exhibits proof of control. Is anything else needed?

I've realized lately that we need to start being a bit more specific on the "authentication" aspect of DIDComm. As I've said in the DIF/didcomm chat, if the keys used to perform DIDComm are not the DID's authentication keys, you are not really authenticating as the DID. You're just demonstrating control of the keys you used that have some relation to the DID.

[llorllale]

@TelegramSam

Request clarification on this issue's intent: is it asking for the user to authenticate to the website or the other way around?

Title of this issue: "Website Authentication"
Description of issue starts with: "Authenticating to a website in an SSI way is a common request."
Your comment above ends with: "Maybe the WebsiteAuthentication Protocol?"

---

Our TrustBloc team has opted for the first approach:

Presentation of a non-identifying credential, which operates like a capability

Although we did not model them as "capabilities"....

Option 2 could be an option to migrate users away from legacy authentication mechanisms.

Option 3 (proof of DID control) is generally not sufficient for us. Although a case could be made for a third-party to present some proof to the website that the DID is in fact a "trusted DID". However, you've now leaked this identifier to the third-party. Whether that's useful or not depends on the use case.

The TrustBloc team uses CHAPI to bootstrap the "connection" and subsequent data exchange between the user's agent and the website. We implemented a custom envelope that includes an OOB invitation. This envelope is transferred to the user's wallet with CHAPI.

[TelegramSam]

In WG 20200930 discussion:

• this is worth pursuing to see what the options are.
• goal code of something like "logintothiswebsite", may be enough without a dedicated protocol.
• remember did from last time enables a QRCode less relogin.

[kdenhartog]

Definitely think having options like this will be useful. Some additional considerations to account for here.

For the first two questions what's contained in the QR code?

• Presentation exchange
• VP request spec
• Presentation request v2
• etc

How is the request being uniquely generated to prevent replay attacks?

How is the recipient managing the state of previously seen DIDs/VCs versus new ones to redirect to a registration flow etc.

Would it be worth trying to integrate DIDs with WebAuthn to handle this as well?

[esune]

OpenID OIDC is a popular option that allows the transfer of credentials as part of the process. For those already involving OpenID, this seems like a good option. For those that are not, this seems like a heavy option.

In what measure is OIDC considered a heavier option than a "pure" VC-based solution? As a developer/company integrating authentication authorization I would likely prefer the solution that involves the least amount of code to be developed on my end, as well as the possibility to integrate with other Identity Providers (not everyone may have or want to use VCs).
For initial adoption, using OIDC seems like it would provide an easy win overall, paving the way for more.

* Presentation of a non-identifying credential, which operates like a capability.
* Presentation of an identifying credential, likely issued by the same website. Will contain an ID. Could also be an email access credential.

Based on the conversation from this morning in the working group, these two scenarios sounded to me like they would be very similar to OIDC solutions. There would be the need to implement mechanisms to track the session, check its validity, renew it when necessary, etc. It could be a lot of overhead to worry about.

* Proof of DID control. This can be done by sending any DIDComm message.

After thinking over this a bit more, I still think that incorporating this step as part of a proof-request rather than having a completely new flow would be overall easier to manage: less code to maintain and one single flow to follow in all cases.
Based on what my understanding is, flow this would anyway be used after the initial registration/authentication (using a regular proof-request mechanism), so the two parties would already know the respective dids and keys used to verify proofs (correct me if I am wrong, these would be the peer did and keys, not necessarily public ones - at least for the holder).
The verifier could request the holder for a self-issued claim - possibly a single-use one, see OTP codes - in addition to whichever other claims are required to satisfy the proof. This could be verified as a predicate, so its value wouldn't even need to be disclosed. This would not be too dissimilar to requesting a proof with a non-revocation interval, meaning it just works as a further restriction on the requested more general proof.
In this case the only new protocol required would be one to handle OTP codes (pairing, rotating, etc.), either from within the agent itself or piggybacking on one of the many OTP apps already out there.

[llorllale]

@kdenhartog

Would it be worth trying to integrate DIDs with WebAuthN to handle this as well?

I like this idea in principle but I'm not sure how it would work?

WebAuthN is probably only suitable for authentication because of its nature and purpose.

WebAuthN is also a web protocol.

The authenticator provides pair-wise credentials (public key) scoped to the relying party.

The authenticator does not reveal PII by design. At most you can get the device's model and the manufacturer's x509 cert, etc.

Yet, for this to work as an authentication method, we would need to fix the credentials somehow. So perhaps we could make the DID subject the WebAuthN relying party.

Flow:

1. create DID
2. perform the WebAuthN registration ceremony and supply the DID ID as relying party ID. You will receive a response with a new fresh credential (public key) that is scoped to this relying party (the DID ID)
3. update your DID with a suitable authentication verification method that contains the public key credential received from the device. Set this verification method's controller to be the DID ID

You can now authenticate as the DID's subject with this verification method.

Beware that since WebAuthN is currently only a web API you have now committed yourself to proxying authentication requests to a browser.

There are UX implications here as well. For one, the browser will not be capable of displaying the right name of the relying party requesting authentication because the WebAuthN credentials were scoped to the DID's subject.

[llorllale]

A more careful reading on verification methods reveals these need not be keys. Theoretically you can shove a service definition inside a verification method section such as authentication.

The "web" constraints would still be there though. This method of DID authentication is effectively restricted to browsers (for now). So if you share the DID via DIDComm and the DID contains such an authentication method, then the DIDComm-aware relying party must initiate a non-DIDComm flow to authenticate the sender of this DID.

This alternative would at least remove the restriction of having scoping the authenticator's credentials to the DID ID. The relying party can now provide their own rpId.

The downside is a DID that only contains this sort of authentication method (which arguably is the minimum requirement, right?) will have very low entropy, if any. The DID method should allow the DID creator to create a DID with sufficient entropy such that its ID is guaranteed to be unique.

[kdenhartog]

Sounds like the WebAuthn integration may not be the best way to focus our efforts for now then. Thanks for the additional insight @llorllale

[PaulWen]

Is anyone still working actively on this topic? I would be happy to contribute!