Address VP Token interop

[OR13]

https://openid.net/specs/openid-4-verifiable-presentations-1_0.html

We need spec text addressing "VP Token" vs "vp+ld+jwt".

cc @Sakurann @selfissued @tplooker

[mprorock]

definitely want input on this

[OR13]

Should we perhaps just say vp_token is not a valid VP?

[Sakurann]

Below is the definition of the VP Token from OID4VP. I think it's pretty clear VP Token != W3C VP?

VP Token: An artifact defined in this specification that contains a single Verifiable Presentation or an array of Verifiable Presentations as defined in Section 6.1.

For W3C VCDM, we probably need to update this Credential Format Profile section in OID4VP

[OR13]

@Sakurann is there a specific typ value for vp_token? Would you be willing to add a PR to address this issue?

[Sakurann]

VP Token is not a JWT in itself (it's a VP itself it or an array of VPs) so no 'typ'.

Do you mean PR in this repo or in OID4VP? (Guess I can do both)

[TallTed]

@Sakurann --

This from you --

I think it's pretty clear VP Token != W3C VP?

-- seems to disagree with this, also from you --

VP Token is not a JWT in itself (it's a VP itself it or an array of VPs) so no 'typ'.

Perhaps you could adjust one or the other (or both), to clarify?

[OR13]

If vp_token is not a JWT, it won't have a typ.

so we can't use typ to distinguish it from vp+ld+jwt.

I think clarifying text should be added in both places, ideally this repo just points to the text in the OIDF spec, and lets it provide the clarity, since it defined vp_token not us.

[andresuribe87]

Just chiming in that I welcome such clarification in both places as well. When I read the OpenID4VC specs initially, I had no idea that VC !== w3c VCDM. It caused me an enormous amount of confusion.

[Sakurann]

here is definition of VP Token fromt the spec:

JSON String or JSON object that MUST contain a single Verifiable Presentation or an array of JSON Strings and JSON objects each of them containing a Verifiable Presentations. Each Verifiable Presentation MUST be represented as a JSON string (that is a Base64url encoded value) or a JSON object depending on a format...

what guidance would be useful on top of this..?

[selfissued]

I marked this as post-CR because normative changes to the spec are not being proposed. These clarifications would be nice-to-have, if someone wants to create PRs.

[decentralgabe]

Should this now include the envelope credentials property?

[selfissued]

@OR13 what concretely would you like us to do for this issue at present, having passed the one-year anniversary of the issue?

[OR13]

It's solved for, we support VPs using enveloped credentials, and the VP data model from the core spec. This issue can be closed

[selfissued]

Closing, per Orie's comment.