Rework iso mdoc/mdl section

[jogu]

We should do something with the ISO mdoc section of VCI; it's not clear about various things - e.g. what exact CBOR object should be returned in the credential response.

It currently says:

string that is the base64url-encoded representation of the issued Credential.

Some implementors are using Document but ISO 23220 part 3 current draft seems to have IssuerSignedDehydrated as the only option in "C.6.9 Credential response" (although IssuerSigned is also mentioned as an option in the intro text in "C.5 Credential Issuance Phase").

One option is to mention ISO 23220 part 3 more explicitly and remove all the other text, similar to what is being done in VP ( https://github.com/openid/OpenID4VP/pull/128 )

[peppelinux]

also linked to this: https://github.com/openid/OpenID4VCI/issues/173

[TakahikoKawasaki]

@jogu Thank you for opening this issue. For example, a paragraph like below will be of help.

In the case that format is mso_mdoc, the value of the credential property in a credential response MUST represent a CBOR data item whose data structure is IssuerSigned, as defined in ISO/IEC 18013-5. However, this requirement MAY be overridden by other standard specifications, such as ISO/IEC 23220-3, which defines a new data structure, IssuerSignedDehydrated, and provides it as an option for the data structure of the credential property.

[Sakurann]

@awoie do you think you would be able to do a PR in VCI explaining relationship between VCI and 23220-3 like you did in VP spec?

[awoie]

We should do something with the ISO mdoc section of VCI; it's not clear about various things - e.g. what exact CBOR object should be returned in the credential response.

It currently says:

string that is the base64url-encoded representation of the issued Credential.

Some implementors are using Document but ISO 23220 part 3 current draft seems to have IssuerSignedDehydrated as the only option in "C.6.9 Credential response" (although IssuerSigned is also mentioned as an option in the intro text in "C.5 Credential Issuance Phase").

@jogu @Sakurann AFAIK, we (ISO context) have first discussed Document but then decided to use IssuerSigned because Document has fields that cannot be used in an issuance flow such as deviceAuth and documentErrors. I know at least 3 implementations of OID4VCI that use IssuerSigned (e.g. CA DMV). How many implementations are there that use Document? (cc @cobward )

[jogu]

How many implementations are there that use Document?

The issuer implementation I was aware of that used Document has now changed to IssuerSigned.

[awoie]

How many implementations are there that use Document?

The issuer implementation I was aware of that used Document has now changed to IssuerSigned.

@Sakurann @jogu : In that case, I would suggest, we say that IssuerSigned is going to be returned from the credential response endpoint. This would ensure that we document the status quo and give existing implementation same safety/interop guarantees.

Once 23220-3 is more stable, it would make sense to refer to 23220-3 (that should define the entire mso_mdoc profile) and explain the relationship to ISO (as @Sakurann suggested) in the same way as we did for OID4VP.

[Sakurann]

ok, so am I correct to understand that 23220-3 is still in flux, so we can't reference it like we referenced 23220-4 in VP? I just looked at the most recent 23220-3 and am a little confused, issuerSignedDehydrated seems to be returned without Document structure, but IssuerSigned only is returned as part of Document structure. I agree this needs to be clarified, and is probably ready for PR if someone knows for sure which structure needs to be returned from the credential response.

[Sakurann]

based on the LSP POTENTIAL interop, it looks like, it should be base64url encoded issuerSigned structure that is returned in the cerdential response

[awoie]

I suggest to wait for an update of the mso/mdoc section after WG4 meeting where the POTENTIAL results will be discussed.

Default option was IssuerSigned, correct.

[awoie]

I created a PR #367 to clarify the expected response and provided a hint for an example. Most common mdocs are typically quite big but I can try to generate one without a portrait picture.

[cobward]

@awoie Just want to point out that the text in the current 23220-3 draft says base64 encoded, whereas here we are saying base64url. I'm a bit out of the loop, so not sure if anyone is actively trying to keep these drafts in sync with each other, but I thought it's worth pointing out here.

[jogu]

Thanks @cobward - we raised that with the 23220-3 author (in particular Matthias in March 2024), and it was raised again on https://gitlab.opencode.de/potential/interop-event/-/issues/9.

As far as I know in 23220-3 it is a mistake and should say base64url, but I've not seen any feedback from ISO either way. I believe implementors are using base64url.

[awoie]

Also note that ISO 23220-3 is a test protocol and we tested it in the POTENTIAL LSP interop event where we actually found that base64url is more appropriate. IMO, ISO 23220-3 should also change that. If not fixed yet, I'll provide feedback to the editor.