Example of did-based sub

[Torsten Lodderstedt]

It is not clear to me, what data the sub and sub_jwk values carry in case of a DID based sub. I think an example would help.

I assume this is the way to go:

‌

{
   "iss":"https://self-issued.me/v2",
   "aud":"https://client.example.org/cb",
   "iat":1615910538,
   "exp":1615911138,
   "auth_time":1615910535,
   "nonce":"960848874",
   "sub":"did:sov:HR6vs6GEZ8rHaVgjg2WodM",
   "sub_jwk":{
      "kid":"did:sov:HR6vs6GEZ8rHaVgjg2WodM#key-1"
   }
}

‌

[Kristina Yasuda]

Right now sub_jwk is a bare JWK. It is required in a current SIOP V2 version even with a DID based sub for compatibility reasons with SIOP in OIDC-CORE ch.7 - so something like

{
   "iss":"https://self-issued.me/v2",
   "aud":"https://client.example.org/cb",
   "iat":1615910538,
   "exp":1615911138,
   "auth_time":1615910535,
   "nonce":"960848874",
   "sub":"did:sov:HR6vs6GEZ8rHaVgjg2WodM",
   sub_jwk" : {
        "crv":"secp256k1",
        "kid":"did:sov:HR6vs6GEZ8rHaVgjg2WodM#key-1",
        "kty":"EC",
        "x":"7KEKZa5xJPh7WVqHJyUpb2MgEe3nA8Rk7eUlXsmBl-M",
        "y":"3zIgl_ml4RhapyEm5J7lvU-4f5jiBvZr4KgxUjEhl9o"
   }
}"

Having said that, there has been some discussion, and I agree that ideally we don't need to use sub_jwk with DID based sub, as long as it matches with header.kid

https://github.com/decentralized-identity/did-siop/issues/43

https://github.com/decentralized-identity/did-siop/issues/45

[Alen Horvat]

Things to consider:

1. wrt the “sub and sub_jwk should be exclusive” statement, see point 4 – there might be a case, where both are required.
2. DID key resolution - RP needs to understand the key format returned by the Universal Resolver or DID Registry. Should we require that all key URIs return key in a JWK format?

3. Relevant point by Torsten: how to ensure that sub_jwk belongs to a DID?

   1. via kid in the header?

4. We need to consider 2 cases:

   1. DID document is publicly resolvable and contains the public keys. In this case kid (link to the DID key) in the header should be sufficient
   2. DID document is publicly resolvable but doesn’t contain public keys (e.g., only ZKPs of key ownership) or DID document is not public. In the first case, the public key needs to be shared, in the 2nd case, both the public key and DID document need to be shared. The first case might be very relevant in EU due to potential GDPR issues if natural person public keys are in a public repository.

‌

Potential info/validation duplication issue:

If ID token contains DID and is signed using a DID key and it carries a Verifiable Presentation, what is the added value of signing the VP? (both ID Token and VP contain audience, sub and signature)

Namely:

• VP contains the DID
• VP contains the proof
• VP contains audience and nonce (linked to the authentication request)

If ID Token and VP are signed using different keys, it may increase the possibility of tracing.

[Alen Horvat]

We used the following example (I put comments in the example):

// JWT encoded ID Token
// JOSE Header
{
  "alg": "ES256K",
  "typ": "JWT",
  "kid": "did:method:0x123abc#authentication-key-3" << Assumption: DID registry returns the key in the PEM or JWK format.
}
// Payload
{
  "iss": "https://self-issued.me/v2",
  "sub": "did:method:0x123abc or {thumbprint of the sub_jwk}", (if sub_jwk is present, sub is thumbprint of the sub_jwk)
  "aud": "did:method:RP-did",
  "iat": 1610714000,
  "exp": 1610714900,
  "sub_jwk":{signing JWK}, << only if DID Document contains ZKP and not the actual keys
  "nonce": "n-0S6_WzA2M",
  "claims": { claims go here }
}

We have the following cases:

• DID and DID key are resolvable: kid = did key uri, sub = did
• DID is resolvable, key is not: kid = did key uri, sub = sub_jwk thumbprint, sub_jwk = did public key
• DID and DID keys are not resolvable: if SIOP and RP already share the DID/DID Document, case 1 covers it; If not, DID Document would also need to be exchanged (as this may be DID method specific, it is not the right place to address it, I guess)

Related to issue: https://bitbucket.org/openid/connect/issues/1261/how-does-rp-determine-sub-type

If the two cases above cover everything, we don’t need the additional info about the sub type.

‌

[Jeremie Miller]

In SIOP v2 section 9.3.1 Sub Types, shouldn’t sub_jwk only be required for the jkt (JWK Thumbprint) type?

The did type definition would then just have a simple statement that the sub value MUST be cryptographically verified against the resolved DID document. And perhaps even with this type, there MUST NOT be a sub_jwk (so as to not cause confusion).

[Kristina Yasuda]

Initial draft at PR #35

[Kristina Yasuda]

the above PR would also resolve Issue #1203

[Kristina Yasuda]

resolved by merging PR #35