Align with ISO/IEC 18013-7 Annex B

[awoie]

The examples for mdoc/mDL are currently not aligned with the latest Annex B text. We should align as soon as Annex B was published. I'd suggest referencing Annex B instead of redefining the flow for mso_mdoc. We can still provide some examples I believe.

[tlodderstedt]

just referencing makes it hard to read as ISO specs are not publicly available

[jogu]

just referencing makes it hard to read as ISO specs are not publicly available

Agreed but I think realistically even with the way it currently is you have zero chance of implementing openid4vp for mdocs without access to the ISO spec?

[awoie]

I double checked the examples and I think they look actually fine now except for the COSE_Mac0 that does not match the presentation_definition but they don't have to strictly align and can be seen as two independent examples. The updated SessionTranscript from part 7 does not have an impact on COSE_Mac0 since the payload (incl. SessionTranscript) is detached and not visible in the CBOR.

@Sakurann @cobward @paulbastian what do you think?

[awoie]

In 18013-7, the vp_token does not contain the DeviceResponse / IssuerSigned directly, it is additionally wrapped in a JWE. But that might be fine in OID4VP since strictly speaking somebody can implement OID4VP with mso_mdoc with/without ISO 18013-7 compliance.

[Sakurann]

the COSE_Mac0 that does not match the presentation_definition

Sorry, could you clarify what you mean by this..?

that might be fine in OID4VP since strictly speaking somebody can implement OID4VP with mso_mdoc with/without ISO 18013-7 compliance.

Yeah, I think the high level question is whether we want to enable OID4VP with mso_mdoc without 18013-7 compliance. If no, we should either remove or strictly align the mso_mdoc examples in OID4VP to 18013-7. If yes, we should define interop profile parameter per discussion in #12 asap and make it clear that examples in OID4VP for mso_mdoc are not necessarily complianet with 18013-7

[jogu]

Yeah, I think the high level question is whether we want to enable OID4VP with mso_mdoc without 18013-7 compliance

It'd seem strange to me to have an alternative to 18013-7 for mdoc+VP unless we have clear demand for it (and I don't think we do) so I would be in favour of strictly aligning the examples.

One thing that's kind of strange to me is that for all the other credential formats the oid4vp profiles are credential-contents agnostic, but for mdoc we only have an mdl profile. Should we have a generic mdoc profile in VP?

[awoie]

@tlodderstedt @jogu @Sakurann it seems that the updated examples for ISO 18013-7 might take a while. I think it is important to update the section ASAP to not confuse developers. This would allow us to cut a new version before we get the updated examples and avoid developer confusion if developers look at the editor's copy or a newly created version of the draft. For that reason I created this PR #128 .

[awoie]

@tlodderstedt @jogu @Sakurann it seems that the updated examples for ISO 18013-7 might take a while. I think it is important to update the section ASAP to not confuse developers. This would allow us to cut a new version before we get the updated examples and avoid developer confusion if developers look at the editor's copy or a newly created version of the draft. For that reason I created this PR #128 .

@selfissued

[sietseringers]

Is there any update on this?

just referencing makes it hard to read as ISO specs are not publicly available

I agree, but with or without deleting the examples as #128 does it might still be a good idea to add the references. In fact, until I noticed this thread here I didn't know that ISO 18013-7 had these examples at all.

In 18013-7, the vp_token does not contain the DeviceResponse / IssuerSigned directly, it is additionally wrapped in a JWE. But that might be fine in OID4VP since strictly speaking somebody can implement OID4VP with mso_mdoc with/without ISO 18013-7 compliance.

In the version of ISO 18013-7 that I have, the value of the vp_token is not a JWE but instead the base64 encoding of a JSON-encoded DeviceResponse.

[jogu]

@sietseringers

In the version of ISO 18013-7 that I have, the value of the vp_token is not a JWE but instead the base64 encoding of a JSON-encoded DeviceResponse.

I think the was just misstated a little; in the latest ISO 18013-7 the response (that contains vp_token) is a JWE.