Minimal DID AuthN Proposal for Interop Project

[awoie]

The DID AuthN SIOP Profile is not ready yet (still needs external review) but we have the need to come up with a protocol for the interop project. @OR13 proposed a simple challenge/response protocol based on JWT. The following is a reduced version of the SIOP DID AuthN Profile:

Simplified SIOP Request

{
   "alg": "ES256K",
   "typ": "JWT",
   "kid": "did:example:0xab#veri-key1"
}
{
    "iss": "did:example:0xab",
    // TBD: SIOP requires the redirect_url as client_id although callback_url would be more natural
    "client_id": "https://my.rp.com/cb",
    "state": "af0ifjsldkj",
    "nonce": "n-0S6_WzA2Mj",
    "response_mode" : "form_post",
    "registration" : {
        "id_token_signed_response_alg" : [ "ES256K", "Ed25519" ],
    }
}

Simplified SIOP Response

{
   "alg": "ES256K",
   "typ": "JWT",
   // optional kid (only if multiple keys were used)
   "kid": "did:example:0xab#key-1"
}
{
   // TBD: SIOP requires a specific value although the did would be more natural
   "iss": "https://self-issued.me",
   "nonce": "n-0S6_WzA2Mj",
   "state": "af0ifjsldkj",
   "exp": 1311281970,
   "iat": 1311280970,
   "did_comm" : {
     "did" : "did:example:0xcd",
     // optional did_doc
     "did_doc" : "..."
   }
}

We could use this protocol as a starting point and then implement the remaining SIOP features on top once the review is finalized. I flagged two items as to-be-discussed because the natural way of naming these two parameters would be different.

[OR13]

Seems like the iss should be the did, or a link to a resolver for the did.

I don't like the idea of embedding the did_doc, but I can see why it might be valuable if the token is used in systems that don't want to resolve a did, as long as the embedded did_doc is signed by the controller of that doc, I think its ok.

the nonce and state are signed by the same DID twice in this example. I don't see how that authenticates the DID holder. They are challenging and responding to themself.

I would expect the end result of this auth flow to result in a JWT that was signed by someone other than the did controller, that the RP trusts, and that the RP would rely on for id_tokens related to DIDs.

is did:example:0xcd supposed to be the sub and should they also be the signer of the response?

[OR13]

It might be helpful to consider SIOP for AuthN of a DID to a regular web server, just so we don't have multiple DIDs in the system. The standards OIDC configuration exposes the JWKs used by an OP, I would exepect the end result of SIOP to be signed with a key lists in .well-known/openid-configuration

[awoie]

@OR13 The SIOP does not require any server. .well-known/openid-configuration won't be available because the SIOP is potentially a identity wallet app.

[awoie]

@OR13 see my comments below:

I don't like the idea of embedding the did_doc, but I can see why it might be valuable if the token is used in systems that don't want to resolve a did, as long as the embedded did_doc is signed by the controller of that doc, I think its ok.

This could be used for peer-DIDs.

the nonce and state are signed by the same DID twice in this example. I don't see how that authenticates the DID holder. They are challenging and responding to themself.

The nonce is generated by the RP, and then included in the signed response. It authenticates the DID holder by proofing control of the DID. The state parameter is just for tracking state information and could be optional.

I would expect the end result of this auth flow to result in a JWT that was signed by someone other than the did controller, that the RP trusts, and that the RP would rely on for id_tokens related to DIDs.

I think you are talking about OpenID Connect? Neither in the minimal spec above, nor in the SIOP spec is any traditional OP required. Additional verifiable credentials are out-of-scope. In theory, a verifiable presentation could be added to the id_token.

is did:example:0xcd supposed to be the sub and should they also be the signer of the response?

yes -- it is not the sub for backward compatibility reasons with the SIOP spec.

[OR13]

@awoie thanks for these comments.

As noted in the interop project, we have adopted the desire to implement a mimimal version of SIOP: decentralized-identity/interoperability#14