[oidc4ci] encoding issued credentials

[Alen Horvat]

https://openid.net/specs/openid-connect-4-verifiable-credential-issuance-1_0.html#section-6.7.3

• credential: OPTIONAL. JSON string that is the base64url encoded representation of the issued credential. MUST be present when acceptance_token is not returned.

Today, the issued credentials are base64url encoded.

For the following signatures:

• JWS
• LD-proofs that use URDNA2015 canonicalization
• JAdES (all profiles, except for the JAdES detached signatures for the baseline-*T* profiles – need to double-check)
• anoncreds (Torsten, can you please check)

the extra encoding is not required as the signing schemes ensure the signature can be validated, even if the order of claims changes during the exchange or processing.

Question:

• Which signatures (if any) are not invariant to claim permutations?

Proposal:

• If there are signatures that aren’t invariant to the claim permutations, make the encoding optional for signatures that don’t protect against claim reordering, etc.

‌

[Giuseppe De Marco]

may we also have mDoc (mDL ISO/IEC 18013-5) in it?

[Alen Horvat]

Yes. It supports all credentials. Do you maybe know the signature format? (just to learn whether one needs to encode the mdoc or not)

[Tobias Looker]

An mDoc is a CBOR based structure so will have to be encoded.

R.e this issue more generally, I agree avoiding unnecessary encoding of JSON based credentials that don’t require it is a good idea, however polymorphic JSON value types in OAuth isn’t a well established pattern I’m familiar with.

[Alen Horvat]

CBOR results with bytes.

In the case of CBOR encoded credentials, the credential format will probably be mdoc_cbor? (instead of vc_jwt or vc_ldp)

So the credential format could also define the signature format/encoding.

vc_jwt → JWS

vc_ldp → LD-Proof

mdoc_cbor → base64url encoded cbor?

[Kristina Yasuda]

sounds like we should take out the requirement that the returned credential is base64url encoded. Do we want to leave it to the external standards (like ISO/IEC 18013-5), interop profiles, or to-be-established registries to specify how each credential format (ie signature scheme) shall be returned in the VP Token? or do we want to have such a table in OIDC4VP spec?

[Alen Horvat]

Yes, I believe this would be the best approach.

[Kristina Yasuda]

During the SIOP call on May 26th, we agreed to take out the requirement that the returned credential is base64url encoded, and include a temporary table in OpenID4VP on how each credential format (ie signature scheme) shall be returned in the VP Token, to reduce dependency on external specifications/registries.

[Kristina Yasuda]

@Alen Horvat I think the same comment also applies to vp_token in OpenID4VP specification. OpenID4VP does not currently mandate the encoding, and implies that whether and how vp_token is encoded is format specific, so would be good to clarify:

`vp_token: a parameter that either directly contains a verifiable presentation or a JSON array with multiple verifiable presentations.`

‌

[Kristina Yasuda]

PR #189

[Alen Horvat]

@Alen Horvat I think the same comment also applies to vp_token in OpenID4VP specification. OpenID4VP does not currently mandate the encoding, and implies that whether and how vp_token is encoded is format specific, so would be good to clarify:

`vp_token: a parameter that either directly contains a verifiable presentation or a JSON array with multiple verifiable presentations.`

Yes. I agree with the update you’re proposing. Should we add that “verifiable presentation encoding is signature format-specific”?

[Kristina Yasuda]

PR #209

‌