Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes mdoc/mdl section #128

Merged
merged 11 commits into from
Apr 3, 2024
89 changes: 47 additions & 42 deletions openid-4-verifiable-presentations-1_0.md
Original file line number Diff line number Diff line change
Expand Up @@ -1292,6 +1292,36 @@ issuers in Self-Sovereign Identity ecosystems using TRAIN</title>
</front>
</reference>

<reference anchor="ISO.18013-7" target="https://www.iso.org/standard/82772.html">
<front>
<title>ISO/IEC DTS 18013-7 Personal identification — ISO-compliant driving license — Part 7: Mobile driving license (mDL) add-on functions</title>
<author>
<organization> ISO/IEC JTC 1/SC 17 Cards and security devices for personal identification</organization>
</author>
<date year="2024"/>
</front>
</reference>

<reference anchor="ISO.23220-2" target="https://www.iso.org/standard/86782.html">
<front>
<title>ISO/IEC DTS 23220-2 Personal identification — Building blocks for identity management via mobile devices, Part 2: Data objects and encoding rules for generic eID systems</title>
<author>
<organization> ISO/IEC JTC 1/SC 17 Cards and security devices for personal identification</organization>
</author>
<date year="2024"/>
</front>
</reference>

<reference anchor="ISO.23220-4" target="https://www.iso.org/standard/86782.html">
<front>
<title>ISO/IEC CD TS 23220-4 Personal identification — Building blocks for identity management via mobile devices, Part 4: Protocols and services for operational phase</title>
<author>
<organization> ISO/IEC JTC 1/SC 17 Cards and security devices for personal identification</organization>
</author>
<date year="2024"/>
</front>
</reference>

<reference anchor="BCP195" target="https://www.rfc-editor.org/info/bcp195">
<front>
<title>BCP195</title>
Expand Down Expand Up @@ -1514,59 +1544,32 @@ The following is the content of the `presentation_definition` parameter:

<{{examples/response/ac_vp_sd.json}}

## ISO mobile Driving License (mDL)
## Mobile Documents or mdocs (ISO/IEC 18013 and ISO/IEC 23220)
awoie marked this conversation as resolved.
Show resolved Hide resolved

This section illustrates how a mobile driving license (mDL) Credential expressed using a data model and data sets defined in [@ISO.18013-5] encoded as CBOR can be presented from the End-User's device directly to the Verifier using this specification.
ISO/IEC 18013-5:2021 [@ISO.18013-5] defines a mobile driving license (mDL) Credential in the mobile document (mdoc) format. Although ISO/IEC 18013-5:2021 [@ISO.18013-5] is specific to mobile driving licenses (mDLs), the Credential format can be utilized with any type of Credential (or mdoc document types). The ISO/IEC 23220 series has extracted components from ISO/IEC 18013-5:2021 [@ISO.18013-5] and ISO/IEC TS 18013-7 [@ISO.18013-7] that are common across document types to facilitate the profiling of the specification for other document types. The core data structures are shared between ISO/IEC 18013-5:2021 [@ISO.18013-5], ISO/IEC 23220-2 [@ISO.23220-2], ISO/IEC 23220-4 [@ISO.23220-4] which are encoded in CBOR and secured using COSE_Sign1.

The Credential format identifier is `mso_mdoc`.
The Credential format identifier for Credentials in the mdoc format is `mso_mdoc`.

Cipher suites should use signature suites names defined in [@ISO.18013-5].
ISO/IEC TS 18013-7 Annex B [@ISO.18013-7] and ISO/IEC 23220-4 [@ISO.23220-4] Annex C define a profile of OID4VP for requesting and presenting Credentials in the mdoc format.

### Presentation Request

A non-normative example of an Authorization Request would look the same as in the examples of other Credential formats in this Annex. The difference is in the content of the `presentation_definition` parameter.

<{{examples/request/request.txt}}

The following is a non-normative example of the content of the `presentation_definition` parameter:

<{{examples/request/pd_mdl_iso_cbor.json}}

To start with, the `format` parameter in the `input_descriptor` element is set to `mso_mdoc`, i.e., it requests presentation of an mDL in CBOR format.
The profile includes the following elements:

To request user claims in ISO/IEC 18013-5:2021 mDL, a `doctype` and `namespace` of the claim needs to be specified. Moreover, the Verifiers needs to indicate whether it intends to retain obtained user claims or not, using `intent_to_retain` property.
* Rules for the `presentation_definition` Authorization Request parameter.
* Rules for the `presentation_submission` Authorization Response parameter.
* Wallet invocation using the `mdoc-openid4vp://` custom URI scheme.
* Rules for the `SessionTranscript` CBOR structure (i.e., the `OID4VPHandover` CBOR structure) and guidelines on using OID4VP Authorization Request and Request Object parameters with the `SessionTranscript` CBOR structure as specified in ISO/IEC TS 18013-7 and ISO/IEC 23220-4.
* Required Wallet and Verifier Metadata parameters and their values.
* Additional restrictions on Authorization Request and Authorization Response parameters to ensure compliance with ISO/IEC TS 18013-7 [@ISO.18013-7] and ISO/IEC 23220-4 [@ISO.23220-4]. For instance, to comply with ISO/IEC TS 18013-7 [@ISO.18013-7], only the same-device flow is supported, the `request_uri` Authorization Request parameter is required, and the Authorization Response has to be encrypted.

Note: `intent_to_retain` is a property introduced in this example to meet requirements of [@ISO.18013-5].
### Presentation Request

Setting `limit_disclosure` property defined in [@!DIF.PresentationExchange] to `required` enables selective release by instructing the Wallet to submit only the data parameters specified in the fields array. Selective release of claims is a requirement built into an ISO/IEC 18013-5:2021 mDL data model.
See ISO/IEC TS 18013-7 Annex B [@ISO.18013-7] and ISO/IEC 23220-4 Annex C [@ISO.23220-4] for the latest examples on how to use the `presentation_definition` parameter for requesting Credentials in the mdoc format.

### Presentation Response

A non-normative example of the Authorization Response would look the same as in the examples of other Credential formats in this Annex.

The following is a non-normative example of the content of the `presentation_submission` parameter:

<{{examples/response/ps_mdl_iso_cbor.json}}

The `descriptor_map` refers to the `input_descriptor` element with an identifier `mDL` and tells the Verifier that there is an ISO/IEC 18013-5:2021 mDL (`format` is `mso_mdoc`) in CBOR encoding directly in the `vp_token` (path is the root designated by `$`).

When ISO/IEC 18013-5:2021 mDL is expressed in CBOR the `path_nested` parameter cannot be used to point to the location of the requested claims. The user claims will always be included in the `issuerSigned` item. `path_nested` parameter can be used, however, when a JSON-encoded ISO/IEC 18013-5:2021 mDL is returned.

The following is a non-normative example of an ISO/IEC 18013-5:2021 mDL encoded as CBOR in diagnostic notation (line wraps within values are for display purposes only) as conveyed in the `vp_token` parameter.

<{{examples/response/mdl_iso_cbor.json}}

In the `deviceSigned` item, the `deviceAuth` item includes a signature by the deviceKey that belongs to the End-User. It is used to prove legitimate possession of the Credential, since the Issuer has signed over the deviceKey during the issuance of the Credential.

Note: The deviceKey does not have to be HW-bound.

In the `issueSigned` item, `issuerAuth` item includes Issuer's signature over the hashes of the user claims, and `namespaces` items include user claims within each namespace that the End-User agreed to reveal to the Verifier in that transaction.

Note: The user claims in the `deviceSigned` item correspond to self-attested claims inside a Self-Issued ID Token [@!SIOPv2] (none in the example below), and user claims in the `issuerSigned` item correspond to the user claims included in a VP Token signed by a trusted third party.

Note: The reason hashes of the user claims are included in the `issuerAuth` item lies in the selective release mechanism. Selective release of the user claims in an ISO/IEC 18013-5:2021 mDL is performed by the Issuer signing over the hashes of all the user claims during the issuance, and only the actual values of the claims that the End-User has agreed to reveal to the Verifier being included during the presentation.
The VP Token contains the base64url encoded `DeviceResponse` CBOR structure as defined in ISO/IEC 18013-5:2021 or ISO/IEC 23220-4. `DeviceResponse` signs over the `SessionTranscript` profile defined in ISO/IEC TS 18013-7 [@ISO.18013-7] and ISO/IEC 23220-4 [@ISO.23220-4].

The example in this section is also applicable to the electronic identification Verifiable Credentials expressed using data models defined in ISO/IEC TR 23220-2.
See ISO/IEC TS 18013-7 Annex B [@ISO.18013-7] and ISO/IEC 23220-4 Annex C [@ISO.23220-4] for the latest examples on how to use the `presentation_submission` parameter and how to generate the Authorizaton Response for presenting Credentials in the mdoc format.

## Combining this specification with SIOPv2

Expand Down Expand Up @@ -1694,6 +1697,8 @@ The technology described in this specification was made available from contribut
# Document History

[[ To be removed from the final specification ]]
-21
awoie marked this conversation as resolved.
Show resolved Hide resolved
* added references to ISO/IEC 23220 and 18013 documents

-20

Expand Down
Loading