Skip to content

Commit

Permalink
Apply suggestions from code review
Browse files Browse the repository at this point in the history
Co-authored-by: Jan Vereecken <jan.vereecken@hey.com>
Co-authored-by: Christian Bormann <8774236+c2bo@users.noreply.github.com>
Co-authored-by: Paul Bastian <paul.bastian@posteo.de>
  • Loading branch information
4 people authored Dec 7, 2024
1 parent ed8a27f commit 4fe9fb3
Showing 1 changed file with 22 additions and 21 deletions.
43 changes: 22 additions & 21 deletions openid4vc-high-assurance-interoperability-profile-1_0.md
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ organization="SPRIND"

.# Abstract

This document defines a profile of OpenID for Verifiable Credentials in combination with the credential format SD-JWT VC and mdoc. The aim is to select features and to define a set of requirements for the existing specifications to enable interoperability among Issuers, Wallets and Verifiers of Credentials where a high level of security and privacy is required. The profiled specifications include OpenID for Verifiable Credential Issuance [@!OIDF.OID4VCI], OpenID for Verifiable Presentations [@!OIDF.OID4VP], Self-Issued OpenID Provider v2 [@!OIDF.SIOPv2], IETF SD-JWT VC [@!I-D.ietf-oauth-sd-jwt-vc], and ISO mdoc [@!ISO.18013-5].
This document defines a profile of OpenID for Verifiable Credentials in combination with the credential formats IETF SD-JWT VC and ISO mdoc. The aim is to select features and to define a set of requirements for the existing specifications to enable interoperability among Issuers, Wallets and Verifiers of Credentials where a high level of security and privacy is required. The profiled specifications include OpenID for Verifiable Credential Issuance [@!OIDF.OID4VCI], OpenID for Verifiable Presentations [@!OIDF.OID4VP], Self-Issued OpenID Provider v2 [@!OIDF.SIOPv2], IETF SD-JWT VC [@!I-D.ietf-oauth-sd-jwt-vc], and ISO mdoc [@!ISO.18013-5].

{mainmatter}

Expand All @@ -40,7 +40,7 @@ This document defines a set of requirements for the existing specifications to e

This document is not a specification, but a profile. It refers to the specifications required for implementations to interoperate among each other and for the optionalities mentioned in the referenced specifications, defines the set of features to be mandatory to implement.

The profile uses OpenID for Verifiable Credential Issuance [@!OIDF.OID4VCI] and OpenID for Verifiable Presentations [@!OIDF.OID4VP] as the base protocols for issuance and presentation of Credentials, respectively. The credential format used is SD-JWT VC as specified in [@!I-D.ietf-oauth-sd-jwt-vc] and ISO mdoc [@!ISO.18013-5]. Additionally, considerations are given on how deployments can perform a combined issuance of credentials in both SD-JWT VC and ISO mdoc [@ISO.18013-5] formats.
The profile uses OpenID for Verifiable Credential Issuance [@!OIDF.OID4VCI] and OpenID for Verifiable Presentations [@!OIDF.OID4VP] as the base protocols for issuance and presentation of Credentials, respectively. The credential formats used are IETF SD-JWT VC as specified in [@!I-D.ietf-oauth-sd-jwt-vc] and ISO mdoc [@!ISO.18013-5]. Additionally, considerations are given on how deployments can perform a combined issuance of credentials in both IETF SD-JWT VC and ISO mdoc [@ISO.18013-5] formats.

A full list of the open standards used in this profile can be found in Overview of the Open Standards Requirements (reference).

Expand All @@ -56,10 +56,10 @@ This specification uses the terms "Holder", "Issuer", "Verifier", and "Verifiabl

The following aspects are in scope of this interoperability profile:

* Profile of OID4VCI to issue IETF SD-JWT VCs (can be both remote and in-person), including
* Profile of OpenID4VCI to issue IETF SD-JWT VCs (can be both remote and in-person), including
* Wallet Attestation
* Profile of OID4VP to present IETF SD-JWT VCs
* Profile of OID4VP over the W3C Digital Credentials API [@w3c.digital_credentials_api] to present
* Profile of OpenID4VP to present IETF SD-JWT VCs
* Profile of OpenID4VP over the W3C Digital Credentials API [@w3c.digital_credentials_api] to present
* IETF SD-JWT VCs
* ISO mdocs
* Protocol for User Authentication by the Wallet at a Verifier (SIOP v2)
Expand All @@ -70,7 +70,7 @@ The following aspects are in scope of this interoperability profile:
* Issuer identification (as prerequisite for trust management)
* Crypto Suites

Note that when OID4VP is used, the Wallet and the Verifier can either be remote or in-person.
Note that when OpenID4VP is used, the Wallet and the Verifier can either be remote or in-person.

Assumptions made are the following:

Expand All @@ -84,8 +84,8 @@ The following items are out of scope for the current version of this document, b

* Trust Management, i.e. authorization of an issuer to issue certain types of credentials, authorization of the Wallet to be issued certain types of credentials, authorization of the Verifier to receive certain types of credentials.
* Protocol for presentation of Verifiable Credentials for offline use-cases, e.g. over BLE.
* Profile of OID4VCI to issue ISO mdocs is defined in ISO 23220-3.
* Profile of OID4VP without using W3C Digital Credentials API to present ISO mdocs is
* Profile of OpenID4VCI to issue ISO mdocs is defined in ISO 23220-3.
* Profile of OpenID4VP without using W3C Digital Credentials API to present ISO mdocs is
defined in [@ISO.18013-7]. For more details, also see Annex B.3 in [@!OIDF.OID4VP].

## Scenarios/Business Requirements
Expand All @@ -96,20 +96,20 @@ defined in [@ISO.18013-7]. For more details, also see Annex B.3 in [@!OIDF.OID4V

## Standards Requirements

This specification enables interoperable implementation of the following four flows:
This specification enables interoperable implementation of the following flows:

* Issuance of IETF SD-JWT VC using OpenID4VCI
* Presentation of IETF SD-JWT VC using OpenID4VP without using W3C Digital Credentials API
* Presentation of IETF SD-JWT VC using OpenID4VP over W3C Digital Credentials API
* Presentation of ISO mdocs using OpenID4VP over W3C Digital Credentials API

Implementations of this specification do not have to implement all of the four flows, but they MUST be compliant to all of the requirements for a particular flow they chose to implement.
Implementations of this specification do not have to implement all of the flows listed above, but they MUST be compliant to all of the requirements for a particular flow they chose to implement.

# OpenID for Verifiable Credential Issuance

The requirements for the Wallet and the Credential Issuer, unless specified otherwise:

* MUST support both pre-auth code flow and authorization code flow.
* MUST support both pre-authorized code flow and authorization code flow.
* MUST support protocol extensions for the SD-JWT VC credential format profile as defined in (#vc_sd_jwt_profile).
* MUST support sender-constrained tokens using the mechanism defined in [@!RFC9449].
* MUST support [@!RFC7636] with `S256` as the code challenge method.
Expand Down Expand Up @@ -206,11 +206,11 @@ This is an example of a Wallet Instance Attestation:

* The Credential Issuer MUST publish a mapping of every Credential Type it supports to a scope value.

# OpenID for Verifiable Presentations profile for SD-JWT VC over HTTPS
# OpenID for Verifiable Presentations profile for IETF SD-JWT VC over HTTPS

The requirements for the Wallet and the Verifier, unless specified otherwise:

* MUST support protocol extensions for SD-JWT VC credential format profile as defined in this specification (#vc_sd_jwt_profile).
* MUST support protocol extensions for IETF SD-JWT VC credential format profile as defined in this specification (#vc_sd_jwt_profile).
* As a way to invoke the Wallet, at least a custom URL scheme `haip://` MUST be supported. Implementations MAY support other ways to invoke the wallets as agreed by trust frameworks/ecosystems/jurisdictions, not limited to using other custom URL schemes.
* Response type MUST be `vp_token`.
* Response mode MUST be `direct_post.jwt`. The Verifier MUST return `redirect_uri` in response to the HTTP POST request from the Wallet, where the Wallet redirects the User to, as defined in Section 7.2 of [@!OIDF.OID4VP]. Implementation considerations for the response mode `direct_post.jwt` are given in Section 12.4 of [@!OIDF.OID4VP].
Expand All @@ -228,25 +228,25 @@ The requirements for the Wallet and the Verifier, unless specified otherwise:

The requirements for the Wallet and the Verifier, unless specified otherwise:

* MUST support Annex A in [@!OIDF.OID4VP] that defines how to use OID4VP over the W3C Digital Credentials API.
* MUST support Annex A in [@!OIDF.OID4VP] that defines how to use OpenID4VP over the W3C Digital Credentials API.
* The Wallet MUST support both signed and unsigned requests defined in Annex A.3.1 and A.3.2 of [@!OIDF.OID4VP]. The Verifier MUST support signed requests, unsigned requests, or both.
* Wallet Invocation is done via the W3C Digital Credentials API or an equivalent platform API. Custom URL schemes MUST NOT be used.
* Response Mode MUST be `dc_api.jwt`. The response MUST be encrypted.
* The DQCL query and response as defined in Section 6 of [@!OIDF.OID4VP] MUST be used. Presentation Exchange as defined in Sections 5.4 and 5.5 of [@!OIDF.OID4VP] MUST NOT be used. Below is the list of features in the DQCL query and response that MUST be supported:
* The DCQL query and response as defined in Section 6 of [@!OIDF.OID4VP] MUST be used. Presentation Exchange as defined in Sections 5.4 and 5.5 of [@!OIDF.OID4VP] MUST NOT be used. Below is the list of features in the DCQL query and response that MUST be supported:
* tbd
* Support for Transaction Data as defined in Sections 5.4 and 7.4 of [@!OIDF.OID4VP] is tbd.

## ISO mdoc specific requirements for OpenID for Verifiable Presentations over W3C Digital Credentials API

* The Credential format identifier MUST be `mso_mdoc`.
* mdoc Credential Format specific DCQL parameters as defined in Section 6.4.2. of [@!OIDF.OID4VP] MUST be used.
* Verifier MAY request more than one credential in the same request.
* When multiple mdocs are being returned, each mdoc should be returned in a separate DeviceResponse, each matching to a respective DCQL query. In this case, resulting in VP Token contains multiple DeviceResponses.
* The Credential Format Identifier MUST be `mso_mdoc`.
* ISO mdoc Credential Format specific DCQL parameters as defined in Annex B.3.1. of [@!OIDF.OID4VP] MUST be used.
* Verifier MAY request more than one Credential in the same request.
* When multiple ISO mdocs are being returned, each ISO mdoc MUST be returned in a separate DeviceResponse (as defined in 8.3.2.1.2.2 of [@!ISO.18013-5]), each matching to a respective DCQL query. Therefore, the resulting `vp_token` contains multiple DeviceResponses.
* Specific requirements for the response encryption are tbd.

### Session Transcript

The SessionTranscript as defined in [@ISO.18013-5] shall be used with the following changes:
The SessionTranscript as defined in Section 9.1.5.1 in [@ISO.18013-5] MUST be used with the following changes:

* DeviceEngagementBytes MUST be null.
* EReaderKeyBytes MUST be null
Expand All @@ -267,7 +267,8 @@ origin = tstr ; using UTF-8
nonce = tstr ; using UTF-8
```

* `clientId` and `nonce` parameters in the Handover MUST be the `client_id` and `nonce` parameters included in the Request from the Verifier.
* "OID4VPDCAPIHandover" is a string that identifies the type of handover structure as a security measure to prevent confusion of handovers.
* `clientId` and `nonce` parameters in the Handover MUST be the `client_id` and `nonce` parameters included in the Authorization Request from the Verifier.
* `origin` in the Handover is the origin of the Verifer, obtained from the Web-platform and/or app platform.

## IETF SD-JWT VC specific requirements for OpenID for Verifiable Presentations over W3C Digital Credentials API
Expand Down

0 comments on commit 4fe9fb3

Please sign in to comment.