vp_jwt/vp_jsonld in id token

tlodderstedt commented 3 years ago

Kristina and Mike re-raised the idea to embed the verifiable presentations into the id token using new claims vp_jwt and vp_jsonld. The idea is to have a universal representation for all formats and possible combinations of signers/signing keys.

Here is an id token example:

{
   "iss":"https://book.itsourweb.org:3000/wallet/wallet.html",
   "aud":"https://book.itsourweb.org:3000/client_api/authresp/uhn",
   "iat":1615910538,
   "exp":1615911138,
   "sub":"urn:uuid:68f874e2-377c-437f-a447-b304967ca351",
   "auth_time":1615910535,
   "vp_jwt":[
      {
         "@context":[
            "https://www.w3.org/2018/credentials/v1",
            "https://ohip.ontario.ca/v1"
         ],
         "type":[
            "VerifiablePresentation"
         ],
         "vp":[
            "ewogICAgImlzcyI6Imh0dHBzOi8vYm9vay5pdHNvdXJ3ZWIub...IH0="
         ]
      }
   ],
   "nonce":"960848874",
   "sub_jwk":{
      "crv":"P-384",
      "ext":true,
      "key_ops":[
         "verify"
      ],
      "kty":"EC",
      "x":"jf3a6dquclZ4PJ0JMU8RuucG9T1O3hpU_S_79sHQi7VZBD9e2VKXPts9lUjaytBm",
      "y":"38VlVE3kNiMEjklFe4Wo4DqdTKkFbK6QrmZf77lCMN2x9bENZoGF2EYFiBsOsnq0"
   }
}

The vp_jwt would be an array containing one or more verifiable presentations in JWT format as defined in the W3C spec:

{
   "iss":"urn:uuid:68f874e2-377c-437f-a447-b304967ca351",
   "jti":"urn:uuid:68f874e2-377c-437f-a447-b304967ca351",
   "aud":"https://book.itsourweb.org:3000/ohip",
   "iat":1615910538,
   "exp":1615911138,
   "nbf":1615910538,
   "nonce":"acIlfiR6AKqGHg",
   "vp":{
      "@context":[
         "https://www.w3.org/2018/credentials/v1",
         "https://ohip.ontario.ca/v1"
      ],
      "type":[
         "VerifiablePresentation"
      ],
      "verifiableCredential":[
         "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6InVybjp1dWlkOjU0ZDk2NjE2LT... OLryT1g"
      ]
   }
}

Rationale:

the "vp as id token" idea overlays VP and ID Token utilizing the same standard claims, like iss, aud, exp, for (potentially) different purposes. This may cause problems.
It is also limited to cases where the issuer of the id token is the holder of the verifiable credential (e.g. SIOP) and uses the same signing key.
the design does not allow for multiple VPs, which is at least required for JWT-based VPs
That's why currently have two concepts, id token as vp and vp_token, which might be more complex than necessary
Putting self contained verifiable presentations in a separate object (an array in case of JWTs) will allow for different signers and fulfils als requirements with one concept.
OPEN: the rationale for introducing the vp_token was the assumption processing of (especially) JWTs and JSON-LD VPs is so different it is better to have separate artefacts. @awoie I understood, you think the new proposal would solve that problem as well?
OPEN: Kim and Admin like the idea of using the vp claims in the id token because of its compatibility with the W3C spec. @AdamJLemmon Can you please comment on this proposal?

AdamJLemmon commented 3 years ago

Thanks @tlodderstedt this is interesting indeed.

Bit unclear on the first example but confirming vp_jwt in the id_token would end up just being an array of base64url encoded JWTs then? Where the decoded payload of each JWT is as defined above from the W3C spec on VP JWT.

...
vp_jwt: [
  "eyJJ9.eyJzDIyfQ.SflKxwRJw5c",
  "eyJJ9.eyJzDIyfQ.SflKxwRJw5c",
  "eyJJ9.eyJzDIyfQ.SflKxwRJw5c",
  "eyJJ9.eyJzDIyfQ.SflKxwRJw5c",
]

> the design does not allow for multiple VPs, which is at least required for JWT-based VPs I'd be curious of a use case where multiple VPs are required? Is this accounting for the case of a Holder having credentials that have been issued to different subject identifiers? Thus requiring multiple proofs to prove control for each unique identifier?

> It is also limited to cases where the issuer of the id token is the holder of the verifiable credential (e.g. SIOP) and uses the same signing key. This makes sense and agreed of the limitation but what would a use case be where a Holder would create a VP and then pass it to an OP to include it in an id_token and present it to the RP on behalf of the Holder? A bit of thinking about here of the power the OP would then have with the Holder's VP in hand perhaps?

selfissued commented 3 years ago

See the actual proposal for the claims to be discussed in tomorrow's OpenID Connect working group call at http://lists.openid.net/pipermail/openid-specs-ab/2021-April/008146.html.

awoie commented 3 years ago

Two comments:

We should call the vp_jsonld claim vp_ldp (LD-Proofs). The W3C VC spec refers to proof formats and the two proof formats that are defined are JWT and LD-Proofs. That is why we should vp_ldp.
Further, it would be great, if we could optionally encrypt the vp_ldp using JWEs. To increase privacy in architectures where the OP is different from the actually Wallet/Agent of the user, we could encrypt the actual W3C VP. We could add a jwe claim in the vp_xyz. The jwe would be encrypted to the RP. Another approach would be to embed a URI in the vp_xyz which points to the Agent endpoint of the end user. The endpoint would provide the actual vp_xyz as a JWE.

Sakurann commented 3 years ago

{
   "iss":"https://book.itsourweb.org:3000/wallet/wallet.html",
   "aud":"https://book.itsourweb.org:3000/client_api/authresp/uhn",
   "iat":1615910538,
   "exp":1615911138,
   "sub":"urn:uuid:68f874e2-377c-437f-a447-b304967ca351",
   "auth_time":1615910535,
   "vp_jwt":[
            "ewogICAgImlzcyI6Imh0dHBzOi8vYm9vay5pdHNvdXJ3ZWIub...IH0="
   ],
   "nonce":"960848874",
   "sub_jwk":{
      "crv":"P-384",
      "ext":true,
      "key_ops":[
         "verify"
      ],
      "kty":"EC",
      "x":"jf3a6dquclZ4PJ0JMU8RuucG9T1O3hpU_S_79sHQi7VZBD9e2VKXPts9lUjaytBm",
      "y":"38VlVE3kNiMEjklFe4Wo4DqdTKkFbK6QrmZf77lCMN2x9bENZoGF2EYFiBsOsnq0"
   }
}

Sakurann commented 3 years ago

{
   "iss":"https://book.itsourweb.org:3000/wallet/wallet.html",
   "aud":"https://book.itsourweb.org:3000/client_api/authresp/uhn",
   "iat":1615910538,
   "exp":1615911138,
   "sub":"urn:uuid:68f874e2-377c-437f-a447-b304967ca351",
   "auth_time":1615910535,
   "vp_ld":[
            LD proof VP 
   ],
   "nonce":"960848874",
   "sub_jwk":{
      "crv":"P-384",
      "ext":true,
      "key_ops":[
         "verify"
      ],
      "kty":"EC",
      "x":"jf3a6dquclZ4PJ0JMU8RuucG9T1O3hpU_S_79sHQi7VZBD9e2VKXPts9lUjaytBm",
      "y":"38VlVE3kNiMEjklFe4Wo4DqdTKkFbK6QrmZf77lCMN2x9bENZoGF2EYFiBsOsnq0"
   }
}

tlodderstedt commented 3 years ago

{
   "iss":"https://book.itsourweb.org:3000/wallet/wallet.html",
   "aud":"https://book.itsourweb.org:3000/client_api/authresp/uhn",
   "iat":1615910538,
   "exp":1615911138,
   "sub":"urn:uuid:68f874e2-377c-437f-a447-b304967ca351",
   "auth_time":1615910535,
   "vp_ldp":{
      "@context":[
         "https://www.w3.org/2018/credentials/v1"
      ],
      "type":[
         "VerifiablePresentation"
      ],
      "verifiableCredential":[
         {
            "@context":[
               "https://www.w3.org/2018/credentials/v1",
               "https://www.w3.org/2018/credentials/examples/v1"
            ],
            "id":"https://example.com/credentials/1872",
            "type":[
               "VerifiableCredential",
               "IDCardCredential"
            ],
            "issuer":{
               "id":"did:example:issuer"
            },
            "issuanceDate":"2010-01-01T19:23:24Z",
            "credentialSubject":{
               "given_name":"Fredrik",
               "family_name":"Strömberg",
               "birthdate":"1949-01-22"
            },
            "proof":{
               "type":"Ed25519Signature2018",
               "created":"2021-03-19T15:30:15Z",
               "jws":"eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..PT8yCqVjj5ZHD0W36zsBQ47oc3El07WGPWaLUuBTOT48IgKI5HDoiFUt9idChT_Zh5s8cF_2cSRWELuD8JQdBw",
               "proofPurpose":"assertionMethod",
               "verificationMethod":"did:example:issuer#keys-1"
            }
         }
      ],
      "id":"ebc6f1c2",
      "holder":"did:example:holder",
      "proof":{
         "type":"Ed25519Signature2018",
         "created":"2021-03-19T15:30:15Z",
         "challenge":"()&)()0__sdf",
         "jws":"eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..GF5Z6TamgNE8QjE3RbiDOj3n_t25_1K7NVWMUASe_OEzQV63GaKdu235MCS3hIYvepcNdQ_ZOKpGNCf0vIAoDA",
         "proofPurpose":"authentication",
         "verificationMethod":"did:example:holder#key-1"
      }
   },
   "nonce":"960848874",
   "sub_jwk":{
      "crv":"P-384",
      "kty":"EC",
      "x":"jf3a6dquclZ4PJ0JMU8RuucG9T1O3hpU_S_79sHQi7VZBD9e2VKXPts9lUjaytBm",
      "y":"38VlVE3kNiMEjklFe4Wo4DqdTKkFbK6QrmZf77lCMN2x9bENZoGF2EYFiBsOsnq0"
   }
}

selfissued commented 3 years ago

FYI, the "JWT Claims for W3C Verifiable Credentials Objects" spec is published at https://openid.bitbucket.io/connect/jwt-claims-for-vc-objects-1_0.html .

awoie / vp-token-spec

vp_jwt/vp_jsonld in id token #16