vp vs. jwt_vp or vp_jwt?

[David W Chadwick]

There is some confusion and inconsistency between the use of the similar claims types vp and jwt_vp (or is it vp_jwt as both are used) in the current document. On the one hand the text says “Note that OP would first encode VPs using the rules defined in the Verifiable Credential specification either in JWT format or JSON-LD format, before encoded VPs as container objects.” and then “Note that above claim has to be distinguished from vp or vc claims as defined in JWT proof format. vp or vc claims contain those parts of the standard verifiable credentials and verifiable presentations where no explicit encoding rules for JWT exist…They are not meant to include complete verifiable credentials or verifiable presentations objects which is the purpose of the claims defined in this specification.”

The W3C definition of vp (and vc) was intended to remove duplicate encodings for the same semantic properties (claims) e.g. iss and issuer, as two different encodings of the same property could lead to problems if the two values were not the same. Which one is to be believed? The text in the current document would appear to be bringing back this duplication and hence potential problems.

Whilst it is appreciated that the W3C text could be improved to remove some ambiguities, it is not a good idea to have two almost identical encodings specified in two different standards and then referring to both in this document in an equally confusing way.

It is suggested that the W3C vp and vc claims are used and that this document contains text to clarify any ambiguities in the W3C standard. This clarifying text can then be inserted into the next revision of the W3C standard. In this way we will only have one agreed specification for vc and vp claims in JWT format.

There is an added complication in that the W3C spec allows a JWT encoding (of vc and vp) to not contain a JWS and instead to contain a proof property, or for it to contain a JWS and to also contain a proof property. It is not clear how the vp_jwt or vp_ldp encodings deal with this issue.

[David Waite]

I am not sure we want id_tokens to also be verifiable presentations.

Semantically, they represent different things

• an id_token is a authentication event about a subject from an issuer
• a VP is an attribute set authorized about a subject by the issuer and released by the holder

An id_token is a statement that to the best of their knowledge, the bearer of the id_token is the subject, hence being tied to an authentication event. VP have no such guarantees.

Also, an id_token is only standardized for bearer or artifact style confirmations today, while VP are pushed to have more key/proof confirmations.

[David Waite]

There are a number of requirements on top of JWTs by both id_tokens and VPs, which would need to both be applied to a combined token that serves both purposes. I attempted to do a quick audit of that here:

1. all URI values MUST NOT be encoded as IRI (I do not believe that VP JWT encoding makes this clarification, but is a requirement for JWT which only supports the defined values being StringOrURI)
2. iss MUST be a HTTPS URI. In particular, this would forbid the issuer from being represented by a DID.
3. sub MUST be present, MUST be a URI, and MUST be under 255 ASCII characters (when encoded as a URI). In addition this conflicts with SIOP today, where sub MUST be a thumbprint.
4. exp MUST be present
5. iat MUST be present and is undefined by the current VP JWT encoding.
6. nbf MUST represent the issuanceDate in the VP (so it is closest to a conflicting naming of iat)
7. jti when present MUST be a URI
8. aud MUST be client_id. Audience is not currently part of the VP data model, so it is unclear whether there would be an assumption on that side that this is a single value or would be required to be a URI.
9. nonce MUST be present when supplied during the request, the VC spec does not mention nonce as it defines a data model rather than a protocol.
10. at_hash and c_hash likewise have defined protocol purposes in id_tokens without corresponding definitions in VP.

In addition,

auth_time, acr, amr, azp do not have a defined meaning or purpose in VP, so I would expect them to be omitted.

Informational claims such as name and address as well as the more metadata claim updated_at should likely be considered mutually exclusive with the vp claim.

The only other claim I know of on this list would be sub_jwk. Because of the conflict with sub in SIOP and the newer value cnf JWT claim, I suspect any proposed resolution would include mandating the use of cnf rather than sub_jwk.

[Kristina Yasuda]

The W3C definition of vp (and vc) was intended to remove duplicate encodings for the same semantic properties (claims) e.g. iss and issuer, as two different encodings of the same property could lead to problems if the two values were not the same. 

Exactly. vp in W3C only contains duplicative encodings and all other non-duplicative vp-specific properies are included in VP outside vp. vp_jwt is proposed to include entire VP (ie both claims in vp and outside it). So I do not see any issue here.

EXAMPLE 31: JWT payload of a JWT based verifiable presentation (non-normative)

{
  "vp_jwt":[
  {
    "iss": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "jti": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
    "aud": "did:example:4a57546973436f6f6c4a4a57573",
    "nbf": 1541493724,
    "iat": 1541493724,
    "exp": 1573029723,
    "nonce": "343s$FSFDa-",
    "vp": {
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://www.w3.org/2018/credentials/examples/v1"
      ],
      "type": ["VerifiablePresentation"],
      // base64url-encoded JWT as string
      "verifiableCredential": ["..."]
    }
   }
  ]
}

‌

[David W Chadwick]

Now I understand the issue. My implementation assumes that the following JSON is the JWT payload for a vp

‌

{
    "iss": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "jti": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
    "aud": "did:example:4a57546973436f6f6c4a4a57573",
    "nbf": 1541493724,
    "iat": 1541493724,
    "exp": 1573029723,
    "nonce": "343s$FSFDa-",
    "vp": {
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://www.w3.org/2018/credentials/examples/v1"
      ],
      "type": ["VerifiablePresentation"],
      // base64url-encoded JWT as string
      "verifiableCredential": ["..."]
    }
   }

So no outer wrapper of vp_jwt is needed. This is how I interpret the W3C standard.

[David W Chadwick]

David Waite. You make some excellent points about where the carrying of VPs in OIDC is deficient in explanation. But this is primarily because the W3C standard was not allowed to specify protocols. So I suggest that the OIDC specs say exactly how VPs have to be carried in OIDC, and where there are ambiguities in the W3C spec we feed these back to W3C to fix in V2 (or in the implementation guidelines in the intervening period)

[Kristina Yasuda]

Is this what you are suggesting? not sure we want to vp claims.

{
    “vp“: 
    {
      "iss": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "jti": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
      "aud": "did:example:4a57546973436f6f6c4a4a57573",
      "nbf": 1541493724,
      "iat": 1541493724,
      "exp": 1573029723,
      "nonce": "343s$FSFDa-",
      "vp": {
        "@context": [
          "https://www.w3.org/2018/credentials/v1",
          "https://www.w3.org/2018/credentials/examples/v1"
        ],
        "type": ["VerifiablePresentation"],
        // base64url-encoded JWT as string
        "verifiableCredential": ["..."]
      }
    }
  }

‌

I suggest that the OIDC specs say exactly how VPs have to be carried in OIDC

This is exactly what OpenID Connect for Verifiable Presentations draft aims to do - it has been recently adopted by the WG and the link is in the Bitbucket repo. Examples in the draft should make it clearer. Please suggest changes if any.

Connect WG call on 2021-05-20 suggested to close this issue.

[David W Chadwick]

Not quite. What we currently send in our protocol is this

‌

{

"vpjwt": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImRpZDpleGFtcGxlOjB4YWJjI2tleTEifQ.eyJpc3MiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEiLCJqdGkiOiJ1cm46dXTmhZaU5yWlhsekxURWlmUS5leUp6Z.....DRxclpBdjZlU2U2UnR4Snk2TTEtbEQ3YTVIVHphbllUV0JQQVVIRFpHeUdLWGRKdy1XX3gwSVdDaEJ6STh0M2twRzI1M2ZnNlYzdFBnSGVLWEU5NGZ6X1FwWWZnLS03a0xzeUJBZlFHYmciXX19.ft_Eq4IniBrr7gtzRfrYj8Vy1aPXuFZU-6_ai0wvaKcsrzI4JkQEKTvbJwdvIeuGuTqy7ipO-EYi7V4TvonPuTRdpB7ZHOlYlbZ4wA9WJ6mSVSqDACvYRiFvrOFmie8rgm6GacWatgO4m4NqiFKFko3r58LueFfGw47NK9RcfOkVQeHCq4btaDqksDKeoTrNysF4YS89INa-prWomrLRAhnwLOo1Etp3E4ESAxg73CR2kA5AoMbf5KtFueWnMcSbQkMRdWcGC1VssC0tB0JffVjq7ZV6OTyV4kl1-UVgiPLXUTpupFfLRhf9QpqMBjYgP62KvhIvW8BbkGUelYMetA"

}

[David W Chadwick]

You will notice the following differences. Currently we do not send a set of VPs as only one is requested by the RP. Secondly the value is the JWT and is not the payload of the JWT.

[Michael Jones]

It was proposed on the 20-May-21 working group call to close this issue, since it's being addressed by the new draft https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0.html .

[David W Chadwick]

I believe this issue can now be closed as the revised draft addresses my concerns.

[Michael Jones]

Resolved, per David Chadwick's comment.