From 094b35bd07322cefcdb90f79c006280960986a72 Mon Sep 17 00:00:00 2001 From: Kristina Yasuda Date: Wed, 20 Nov 2024 19:06:59 +0100 Subject: [PATCH 01/20] refactor and add details for mdoc profile over the oid4vp browser API --- ...-interoperability-profile-sd-jwt-vc-1_0.md | 123 ++++++++++++++---- 1 file changed, 101 insertions(+), 22 deletions(-) diff --git a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md index cbe89c8..b48feba 100644 --- a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md @@ -1,13 +1,13 @@ %%% -title = "OpenID4VC High Assurance Interoperability Profile with SD-JWT VC - draft 01" -abbrev = "openid4vc-high-assurance-interoperability-profile-sd-jwt-vc" +title = "OpenID4VC High Assurance Interoperability Profile - draft 01" +abbrev = "openid4vc-high-assurance-interoperability-profile" ipr = "none" workgroup = "Digital Credentials Protocols" -keyword = ["security", "openid4vc", "sd-jwt", "sd-jwt-vc"] +keyword = ["security", "openid4vc", "sd-jwt", "sd-jwt-vc", "mdoc"] [seriesInfo] name = "Internet-Draft" -value = "openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0-01" +value = "openid4vc-high-assurance-interoperability-profile-1_0-01" status = "standard" [[author]] @@ -30,7 +30,7 @@ organization="sprind.org" .# Abstract -This document defines a profile of OpenID for Verifiable Credentials in combination with the credential format SD-JWT VC. 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], and SD-JWT VC [@!I-D.ietf-oauth-sd-jwt-vc]. +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]. {mainmatter} @@ -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]. 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 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. A full list of the open standards used in this profile can be found in Overview of the Open Standards Requirements (reference). @@ -56,17 +56,22 @@ This specification uses the terms "Holder", "Issuer", "Verifier", and "Verifiabl The following aspects are in scope of this interoperability profile: -* Protocol for issuance of the Verifiable Credentials (can be both remote and in-person) (OID4VCI) -* Protocol for online presentation of Verifiable Credentials (can be both remote and in-person) (OID4VP) +* Profile of OID4VCI to issue IETF SD-JWT VCs (can be both remote and in-person), including + * Wallet Attestation +* Profile of OID4VP without using W3C Digital Credentials API [@w3c.digital_credentials_api] to present IETF SD-JWT VCs +* Profile of OID4VP over W3C Digital Credentials API to present + * IETF SD-JWT VCs + * ISO mdocs * Protocol for User Authentication by the Wallet at a Verifier (SIOP v2) -* Wallet Attestation (during Credential issuance) -* Credential Format (SD-JWT VC) -* Status Management of the Credentials, including revocation -* Cryptographic Holder Binding -* Issuer key resolution -* Issuer identification (as prerequisite for trust management) +* Profile of IETF SD-JWT VC that includes the following aspects + * Status Management of the Credentials, including revocation + * Cryptographic Holder Binding + * Issuer key resolution + * Issuer identification (as prerequisite for trust management) * Crypto Suites +Note that when OID4VP is used, the Wallet and the Verifier can either be remote and in-person. + Assumptions made are the following: * The issuers and verifiers cannot pre-discover wallet’s capability @@ -79,6 +84,7 @@ 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 OID4VP 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 @@ -88,14 +94,14 @@ The following items are out of scope for the current version of this document, b ## Standards Requirements -Unless explicitly stated, all normative requirements apply to all participating entities: Issuers, Wallets and Verifiers. +This specification enable interoperable implementation of the following four flows: + +* Issuance of IETF SD-JWT VC using OpenID4VCI +* Presentation of IETF SD-JWT VC using OpenID4VP +* Presentation of IETF SD-JWT VC using OpenID4VP over W3C Digital Credentials API +* Presentation of ISO mdocs using OpenID4VP over W3C Digital Credentials API -| (as defined in this profile) | Issuer | Wallet | Verifier | -|:--- |:--- |:--- |:--- | -|OID4VP| N/A |MUST|MUST| -|OID4VCI| MUST|MUST|N/A| -|SIOPv2|N/A|MUST|SHOULD| -|SD-JWT VC profile as defined in (#sd-jwt-vc) |MUST|MUST|MUST| +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. # OpenID for Verifiable Credential Issuance @@ -198,7 +204,7 @@ 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 +# OpenID for Verifiable Presentations without using W3C Digital Credentials API * MUST support protocol extensions for 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. @@ -215,6 +221,57 @@ This is an example of a Wallet Instance Attestation: * In the `input-descriptors` object, `id`, `name`, `purpose`, `group`, `format`, and `constraints` properties MUST be supported. In the `constraints` object, `limit_disclosure`, and `fields` properties MUST be supported. In the `fields` object, `path` and `filter` properties MUST be supported. A `path` MUST contain exactly one entry with a static path to a certain claim. A `filter` MUST only contain `type` elements of value `string` and `const` elements. * In the `submission_requirements` object, `name`, `rule (`pick` only)`, `count`, `from` properties MUST be supported. +# OpenID for Verifiable Presentations over W3C Digital Credentials API + +* MUST support Annex A in [@!OIDF.OID4VP] that defines how to use OID4VP over the W3C Digital Credentials API. + * Annex A.3.1. in [@!OIDF.OID4VP] MUST NOT be used. OID4VP requests over the W3C Digital Credentials API MUST be signed. +* 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 `w3c_dc_api.jwt`. Encryption of the response is mandatory. +* MUST support Transaction Data defined in Sections 5.4 and 7.4 of [@!OIDF.OID4VP]. +* 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: + * 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. + * DeviceResponse in the VP Token MUST contain only one mdoc. Therefore, when multiple mdocs are being returned, each mdoc should be returned in a separate DeviceResponse, each matching to a respective DCQL query. + * Response encryption MUST be done as defined in Section B.4.3.3.2 in [@!ISO.18013-7]. + +### Session Transcript + +The SessionTranscript as defined in [@ISO.18013-5] shall be used with the following changes: + +* DeviceEngagementBytes MUST be null. +* EReaderKeyBytes MUST ne null + +The Handover element is defined as following: + +``` +Handover = OID4VPDCAPIHandover +OID4VPDCAPIHandover = [ + "OID4VPDCAPIHandover" + clintId + origin + nonce +] + +clientId = tstr +origin = tstr +nonce = tstr +``` + +* `clientId` and `nonce` parameters in the Handover MUST be the `client_id` and `nonce` parameters included in the 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 + + * The Credential format identifier MUST be `dc+sd-jwt`. + * IETF SD-JWT VC Credential Format specific DCQL parameters as defined in Section 6.4.1. of [@!OIDF.OID4VP] MUST be used. + * When Key Binding JWT is used, `aud` value in it MUST be the origin of the Verifer, obtained from the Web-platform and/or app platform, and not `client_id` received in the Request. + + # Self-Issued OP v2 To authenticate the user, subject identifier in a Self-Issued ID Token MUST be used as defined in [@!OIDF.SIOPv2]. @@ -384,6 +441,28 @@ Note: When using this profile with other cryptosuites, it is recommended to be e + + + ISO/IEC DTS 18013-7 Personal identification — ISO-compliant driving license — Part 7: Mobile driving license (mDL) add-on functions + + ISO/IEC JTC 1/SC 17 Cards and security devices for personal identification + + + + + + + + Digital Credentials API + + Apple Inc. + + + Google + + + + Verifiable Credentials Data Model v2.0 From 95bcf02721fc5899ef874344602550f1bb7f0fcb Mon Sep 17 00:00:00 2001 From: Kristina <52878547+Sakurann@users.noreply.github.com> Date: Fri, 22 Nov 2024 00:03:07 +0100 Subject: [PATCH 02/20] Apply suggestions from Brian's code review Co-authored-by: Brian Campbell <71398439+bc-pi@users.noreply.github.com> Co-authored-by: Jan Vereecken --- ...surance-interoperability-profile-sd-jwt-vc-1_0.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md index b48feba..fd7b013 100644 --- a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md @@ -58,8 +58,8 @@ 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 * Wallet Attestation -* Profile of OID4VP without using W3C Digital Credentials API [@w3c.digital_credentials_api] to present IETF SD-JWT VCs -* Profile of OID4VP over W3C Digital Credentials API to present +* Profile of OID4VP to present IETF SD-JWT VCs +* Profile of OID4VP 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) @@ -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 and in-person. +Note that when OID4VP is used, the Wallet and the Verifier can either be remote or in-person. Assumptions made are the following: @@ -84,7 +84,9 @@ 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 OID4VP 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]. +* 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 +defined in [@!ISO.18013-7]. For more details, also see Annex B.3 in [@!OIDF.OID4VP]. ## Scenarios/Business Requirements @@ -252,7 +254,7 @@ The Handover element is defined as following: Handover = OID4VPDCAPIHandover OID4VPDCAPIHandover = [ "OID4VPDCAPIHandover" - clintId + clientId origin nonce ] From 2f4b2ec36f603c08a725ccc633e6a58012fb4737 Mon Sep 17 00:00:00 2001 From: Kristina Yasuda Date: Thu, 28 Nov 2024 21:26:17 +0100 Subject: [PATCH 03/20] allow both signed and unsigned requests. mandate both for the wallet, clarify that the verifier has a choice --- ...4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md index fd7b013..8b17fc2 100644 --- a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md @@ -226,7 +226,7 @@ This is an example of a Wallet Instance Attestation: # OpenID for Verifiable Presentations over W3C Digital Credentials API * MUST support Annex A in [@!OIDF.OID4VP] that defines how to use OID4VP over the W3C Digital Credentials API. - * Annex A.3.1. in [@!OIDF.OID4VP] MUST NOT be used. OID4VP requests over the W3C Digital Credentials API MUST be signed. + * 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 and/or unsigned requests. * 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 `w3c_dc_api.jwt`. Encryption of the response is mandatory. * MUST support Transaction Data defined in Sections 5.4 and 7.4 of [@!OIDF.OID4VP]. From 77aa345cf257e31936f84db48742076ac9d96fa0 Mon Sep 17 00:00:00 2001 From: Kristina <52878547+Sakurann@users.noreply.github.com> Date: Thu, 28 Nov 2024 21:38:53 +0100 Subject: [PATCH 04/20] Apply editorial suggestions from Joseph's code review Co-authored-by: Joseph Heenan --- ...high-assurance-interoperability-profile-sd-jwt-vc-1_0.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md index 8b17fc2..c74819e 100644 --- a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md @@ -96,10 +96,10 @@ defined in [@!ISO.18013-7]. For more details, also see Annex B.3 in [@!OIDF.OID4 ## Standards Requirements -This specification enable interoperable implementation of the following four flows: +This specification enables interoperable implementation of the following four flows: * Issuance of IETF SD-JWT VC using OpenID4VCI -* Presentation of IETF SD-JWT VC using OpenID4VP +* 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 @@ -206,7 +206,7 @@ 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 without using W3C Digital Credentials API +# OpenID for Verifiable Presentations profile for SD-JWT VC without using W3C Digital Credentials API * MUST support protocol extensions for 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. From 796886b515e03c3cf3cbdef930f4a2165f47ab61 Mon Sep 17 00:00:00 2001 From: Kristina <52878547+Sakurann@users.noreply.github.com> Date: Thu, 28 Nov 2024 21:44:00 +0100 Subject: [PATCH 05/20] remove restrictions to KB JWT aud Co-authored-by: Joseph Heenan --- ...d4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md | 1 - 1 file changed, 1 deletion(-) diff --git a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md index c74819e..4227754 100644 --- a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md @@ -271,7 +271,6 @@ nonce = tstr * The Credential format identifier MUST be `dc+sd-jwt`. * IETF SD-JWT VC Credential Format specific DCQL parameters as defined in Section 6.4.1. of [@!OIDF.OID4VP] MUST be used. - * When Key Binding JWT is used, `aud` value in it MUST be the origin of the Verifer, obtained from the Web-platform and/or app platform, and not `client_id` received in the Request. # Self-Issued OP v2 From cb19041486885a43405a7c2bd3c880b280efd315 Mon Sep 17 00:00:00 2001 From: Kristina Yasuda Date: Thu, 28 Nov 2024 21:32:21 +0100 Subject: [PATCH 06/20] clarify the unless otherwise stated requirements apply to all entities --- ...assurance-interoperability-profile-sd-jwt-vc-1_0.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md index 4227754..6290aa3 100644 --- a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md @@ -107,7 +107,7 @@ Implementations of this specification do not have to implement all of the four f # OpenID for Verifiable Credential Issuance -Implementations of this profile: +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 protocol extensions for the SD-JWT VC credential format profile as defined in (#vc_sd_jwt_profile). @@ -208,6 +208,8 @@ This is an example of a Wallet Instance Attestation: # OpenID for Verifiable Presentations profile for SD-JWT VC without using W3C Digital Credentials API +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). * 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`. @@ -225,6 +227,8 @@ This is an example of a Wallet Instance Attestation: # OpenID for Verifiable Presentations over W3C Digital Credentials API +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. * 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 and/or unsigned requests. * Wallet Invocation is done via the W3C Digital Credentials API or an equivalent platform API. Custom URL schemes MUST NOT be used. @@ -282,9 +286,7 @@ To authenticate the user, subject identifier in a Self-Issued ID Token MUST be u # SD-JWT VCs {#sd-jwt-vc} -As credential format, SD-JWT VCs as defined in [@!I-D.ietf-oauth-sd-jwt-vc] MUST be used. - -In addition, this profile defines the following additional requirements. +This profile defines the following additional requirements for SD-JWT VCs as defined in [@!I-D.ietf-oauth-sd-jwt-vc]. * Compact serialization MUST be supported as defined in [@!I-D.ietf-oauth-selective-disclosure-jwt]. JSON serialization MAY be supported. * The following JWT Claims MUST be supported Content (differentiate issuance & presentation) From 85bef244090f3c2327328af81f89d17ecb8ecc34 Mon Sep 17 00:00:00 2001 From: Kristina Yasuda Date: Thu, 28 Nov 2024 21:33:35 +0100 Subject: [PATCH 07/20] remove the requirement to support transaction data and put a placeholder --- ...vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md index 6290aa3..8846955 100644 --- a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md @@ -233,9 +233,10 @@ The requirements for the Wallet and the Verifier, unless specified otherwise: * 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 and/or unsigned requests. * 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 `w3c_dc_api.jwt`. Encryption of the response is mandatory. -* MUST support Transaction Data defined in Sections 5.4 and 7.4 of [@!OIDF.OID4VP]. * 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: * 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 From 013c1fd6f9cacfbb9c3e74e58ef7da730fac66a3 Mon Sep 17 00:00:00 2001 From: Kristina Yasuda Date: Thu, 28 Nov 2024 21:37:34 +0100 Subject: [PATCH 08/20] remove reference to 18013-7 and specific requirements for JWE with mdocs --- ...vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md index 8846955..cbbcf87 100644 --- a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md @@ -237,14 +237,13 @@ The requirements for the Wallet and the Verifier, unless specified otherwise: * 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. * DeviceResponse in the VP Token MUST contain only one mdoc. Therefore, when multiple mdocs are being returned, each mdoc should be returned in a separate DeviceResponse, each matching to a respective DCQL query. - * Response encryption MUST be done as defined in Section B.4.3.3.2 in [@!ISO.18013-7]. + * Specific requirements for the response encryption are tbd. ### Session Transcript From c45eb79ccd8d0d29e129c4a39c90050585014a8d Mon Sep 17 00:00:00 2001 From: Kristina <52878547+Sakurann@users.noreply.github.com> Date: Tue, 3 Dec 2024 10:55:13 +0100 Subject: [PATCH 09/20] Apply suggestions from code review Co-authored-by: Joseph Heenan Co-authored-by: Oliver Terbu Co-authored-by: Christian Bormann <8774236+c2bo@users.noreply.github.com> --- ...-interoperability-profile-sd-jwt-vc-1_0.md | 26 +++++++++++++------ 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md index cbbcf87..038202b 100644 --- a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md @@ -84,9 +84,9 @@ 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 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 -defined in [@!ISO.18013-7]. For more details, also see Annex B.3 in [@!OIDF.OID4VP]. +defined in [@ISO.18013-7]. For more details, also see Annex B.3 in [@!OIDF.OID4VP]. ## Scenarios/Business Requirements @@ -230,9 +230,9 @@ 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. - * 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 and/or unsigned requests. + * 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 `w3c_dc_api.jwt`. Encryption of the response is mandatory. +* 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: * tbd * Support for Transaction Data as defined in Sections 5.4 and 7.4 of [@!OIDF.OID4VP] is tbd. @@ -250,7 +250,7 @@ The requirements for the Wallet and the Verifier, unless specified otherwise: The SessionTranscript as defined in [@ISO.18013-5] shall be used with the following changes: * DeviceEngagementBytes MUST be null. -* EReaderKeyBytes MUST ne null +* EReaderKeyBytes MUST be null The Handover element is defined as following: @@ -263,9 +263,9 @@ OID4VPDCAPIHandover = [ nonce ] -clientId = tstr -origin = tstr -nonce = tstr +clientId = tstr ; using UTF-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. @@ -454,6 +454,16 @@ Note: When using this profile with other cryptosuites, it is recommended to be e + + + ISO/IEC DTS 23220-3 Cards and security devices for personal identification — Building blocks for identity management via mobile devices + + ISO/IEC JTC 1/SC 17 Cards and security devices for personal identification + + + + + Digital Credentials API From 1465f18649f92badea8a1b41050a744d2e9675ed Mon Sep 17 00:00:00 2001 From: Joseph Heenan Date: Tue, 3 Dec 2024 19:52:44 +0900 Subject: [PATCH 10/20] Attempt to fix pipeline Pushed with Kristina's permission --- .github/workflows/Build-oid4vc-haip-sd-jwt-vc.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/Build-oid4vc-haip-sd-jwt-vc.yml b/.github/workflows/Build-oid4vc-haip-sd-jwt-vc.yml index ceb583a..83129d3 100644 --- a/.github/workflows/Build-oid4vc-haip-sd-jwt-vc.yml +++ b/.github/workflows/Build-oid4vc-haip-sd-jwt-vc.yml @@ -18,7 +18,7 @@ jobs: openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md - name: rename run: | - mv ./openid4vc-high-assurance-interoperability-profile-sd-jwt-vc*.html ./openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-wg-draft.html + mv ./openid4vc-high-assurance-interoperability-profile*.html ./openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-wg-draft.html - uses: actions/upload-artifact@v3 with: # Artifact name From 02740b19b99054adb4ff260adfa0337d2ca54801 Mon Sep 17 00:00:00 2001 From: Kristina <52878547+Sakurann@users.noreply.github.com> Date: Thu, 5 Dec 2024 03:29:19 +0100 Subject: [PATCH 11/20] Apply suggestions from code review Co-authored-by: Torsten Lodderstedt --- ...c-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md index 038202b..145c2c2 100644 --- a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md @@ -206,7 +206,7 @@ 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 without using W3C Digital Credentials API +# OpenID for Verifiable Presentations profile for SD-JWT VC over HTTPS The requirements for the Wallet and the Verifier, unless specified otherwise: @@ -242,7 +242,7 @@ The requirements for the Wallet and the Verifier, unless specified otherwise: * 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. - * DeviceResponse in the VP Token MUST contain only one mdoc. Therefore, when multiple mdocs are being returned, each mdoc should be returned in a separate DeviceResponse, each matching to a respective DCQL query. + * 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. * Specific requirements for the response encryption are tbd. ### Session Transcript From 4fe9fb35e6ff84c4dd6c10a7ccf8ece34ecdc452 Mon Sep 17 00:00:00 2001 From: Kristina <52878547+Sakurann@users.noreply.github.com> Date: Sat, 7 Dec 2024 07:36:21 +0100 Subject: [PATCH 12/20] Apply suggestions from code review Co-authored-by: Jan Vereecken Co-authored-by: Christian Bormann <8774236+c2bo@users.noreply.github.com> Co-authored-by: Paul Bastian --- ...-assurance-interoperability-profile-1_0.md | 43 ++++++++++--------- 1 file changed, 22 insertions(+), 21 deletions(-) diff --git a/openid4vc-high-assurance-interoperability-profile-1_0.md b/openid4vc-high-assurance-interoperability-profile-1_0.md index 6300411..62ebcbe 100644 --- a/openid4vc-high-assurance-interoperability-profile-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-1_0.md @@ -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} @@ -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). @@ -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) @@ -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: @@ -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 @@ -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. @@ -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]. @@ -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 @@ -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 From aaf7d879db2803a99547afbca26cf4b6c9e85221 Mon Sep 17 00:00:00 2001 From: Kristina <52878547+Sakurann@users.noreply.github.com> Date: Sat, 7 Dec 2024 07:41:18 +0100 Subject: [PATCH 13/20] temporarily removing reference to the transaction data from HAIP --- openid4vc-high-assurance-interoperability-profile-1_0.md | 1 - 1 file changed, 1 deletion(-) diff --git a/openid4vc-high-assurance-interoperability-profile-1_0.md b/openid4vc-high-assurance-interoperability-profile-1_0.md index 62ebcbe..0f1762a 100644 --- a/openid4vc-high-assurance-interoperability-profile-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-1_0.md @@ -234,7 +234,6 @@ The requirements for the Wallet and the Verifier, unless specified otherwise: * Response Mode MUST be `dc_api.jwt`. The response MUST be encrypted. * 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 From 79514e1bc9917cb90f3cbca1816b06a4269528c9 Mon Sep 17 00:00:00 2001 From: Kristina <52878547+Sakurann@users.noreply.github.com> Date: Sat, 7 Dec 2024 07:44:03 +0100 Subject: [PATCH 14/20] moving transaction data to a section that describes both sd-jwt and mdocs --- openid4vc-high-assurance-interoperability-profile-1_0.md | 1 + 1 file changed, 1 insertion(+) diff --git a/openid4vc-high-assurance-interoperability-profile-1_0.md b/openid4vc-high-assurance-interoperability-profile-1_0.md index 0f1762a..fdc1ccc 100644 --- a/openid4vc-high-assurance-interoperability-profile-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-1_0.md @@ -232,6 +232,7 @@ The requirements for the Wallet and the Verifier, unless specified otherwise: * 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. +* Specific requirements for the response encryption are tbd. * 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 From 1e5abe7433695d78c7fb952ca5c29d81f555e15d Mon Sep 17 00:00:00 2001 From: Kristina <52878547+Sakurann@users.noreply.github.com> Date: Sat, 7 Dec 2024 07:44:24 +0100 Subject: [PATCH 15/20] remove encryption section from mdoc specific section --- openid4vc-high-assurance-interoperability-profile-1_0.md | 1 - 1 file changed, 1 deletion(-) diff --git a/openid4vc-high-assurance-interoperability-profile-1_0.md b/openid4vc-high-assurance-interoperability-profile-1_0.md index fdc1ccc..69a2ad1 100644 --- a/openid4vc-high-assurance-interoperability-profile-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-1_0.md @@ -242,7 +242,6 @@ The requirements for the Wallet and the Verifier, unless specified otherwise: * 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 From 71de98eab718a48aeef05e17ddeb5bb4a2a926f8 Mon Sep 17 00:00:00 2001 From: Kristina <52878547+Sakurann@users.noreply.github.com> Date: Thu, 12 Dec 2024 13:42:00 +0100 Subject: [PATCH 16/20] Apply suggestions from code review Co-authored-by: Jan Vereecken Co-authored-by: Christian Bormann <8774236+c2bo@users.noreply.github.com> --- ...c-high-assurance-interoperability-profile-1_0.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/openid4vc-high-assurance-interoperability-profile-1_0.md b/openid4vc-high-assurance-interoperability-profile-1_0.md index 69a2ad1..dd89ccb 100644 --- a/openid4vc-high-assurance-interoperability-profile-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-1_0.md @@ -65,7 +65,7 @@ The following aspects are in scope of this interoperability profile: * Protocol for User Authentication by the Wallet at a Verifier (SIOP v2) * Profile of IETF SD-JWT VC that includes the following aspects * Status Management of the Credentials, including revocation - * Cryptographic Holder Binding + * Cryptographic Key Binding * Issuer key resolution * Issuer identification (as prerequisite for trust management) * Crypto Suites @@ -226,10 +226,10 @@ The requirements for the Wallet and the Verifier, unless specified otherwise: # OpenID for Verifiable Presentations over W3C Digital Credentials API -The requirements for the Wallet and the Verifier, unless specified otherwise: +The following requirements apply for both, the Wallet and the Verifier, unless specified otherwise: * 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. + * The Wallet MUST support both signed and unsigned requests as 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. * Specific requirements for the response encryption are tbd. @@ -272,7 +272,7 @@ nonce = tstr ; using UTF-8 ## IETF SD-JWT VC specific requirements for OpenID for Verifiable Presentations over W3C Digital Credentials API - * The Credential format identifier MUST be `dc+sd-jwt`. + * The Credential Format identifier MUST be `dc+sd-jwt`. * IETF SD-JWT VC Credential Format specific DCQL parameters as defined in Section 6.4.1. of [@!OIDF.OID4VP] MUST be used. @@ -285,7 +285,7 @@ To authenticate the user, subject identifier in a Self-Issued ID Token MUST be u # SD-JWT VCs {#sd-jwt-vc} -This profile defines the following additional requirements for SD-JWT VCs as defined in [@!I-D.ietf-oauth-sd-jwt-vc]. +This profile defines the following additional requirements for IETF SD-JWT VCs as defined in [@!I-D.ietf-oauth-sd-jwt-vc]. * Compact serialization MUST be supported as defined in [@!I-D.ietf-oauth-selective-disclosure-jwt]. JSON serialization MAY be supported. * The following JWT Claims MUST be supported Content (differentiate issuance & presentation) @@ -472,6 +472,9 @@ Note: When using this profile with other cryptosuites, it is recommended to be e Google + + Okta + From 680abc256ff5a39fcecaaa9159063c24e4524ae0 Mon Sep 17 00:00:00 2001 From: Kristina <52878547+Sakurann@users.noreply.github.com> Date: Thu, 12 Dec 2024 13:43:13 +0100 Subject: [PATCH 17/20] removing (can be both remote and in-person) --- openid4vc-high-assurance-interoperability-profile-1_0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openid4vc-high-assurance-interoperability-profile-1_0.md b/openid4vc-high-assurance-interoperability-profile-1_0.md index dd89ccb..6d137c3 100644 --- a/openid4vc-high-assurance-interoperability-profile-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-1_0.md @@ -56,7 +56,7 @@ This specification uses the terms "Holder", "Issuer", "Verifier", and "Verifiabl The following aspects are in scope of this interoperability profile: -* Profile of OpenID4VCI to issue IETF SD-JWT VCs (can be both remote and in-person), including +* Profile of OpenID4VCI to issue IETF SD-JWT VCs, including * Wallet Attestation * Profile of OpenID4VP to present IETF SD-JWT VCs * Profile of OpenID4VP over the W3C Digital Credentials API [@w3c.digital_credentials_api] to present From 42aca218e08952d9561e3a93464458ee360ed55e Mon Sep 17 00:00:00 2001 From: Kristina <52878547+Sakurann@users.noreply.github.com> Date: Thu, 12 Dec 2024 13:44:47 +0100 Subject: [PATCH 18/20] Apply suggestions from code review --- openid4vc-high-assurance-interoperability-profile-1_0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openid4vc-high-assurance-interoperability-profile-1_0.md b/openid4vc-high-assurance-interoperability-profile-1_0.md index 6d137c3..89a074c 100644 --- a/openid4vc-high-assurance-interoperability-profile-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-1_0.md @@ -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 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. +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 the issuance of Credentials in both IETF SD-JWT VC and ISO mdoc [@ISO.18013-5] formats can be performed in the same transaction. A full list of the open standards used in this profile can be found in Overview of the Open Standards Requirements (reference). From 803272d91a3ad05034cafa3446469ec32f7810ec Mon Sep 17 00:00:00 2001 From: Kristina <52878547+Sakurann@users.noreply.github.com> Date: Thu, 12 Dec 2024 16:39:39 +0100 Subject: [PATCH 19/20] Apply suggestions from code review Co-authored-by: Daniel Fett --- ...gh-assurance-interoperability-profile-1_0.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/openid4vc-high-assurance-interoperability-profile-1_0.md b/openid4vc-high-assurance-interoperability-profile-1_0.md index 89a074c..9b1a55c 100644 --- a/openid4vc-high-assurance-interoperability-profile-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-1_0.md @@ -96,7 +96,7 @@ 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 flows: +This specification enables interoperable implementations 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 @@ -107,7 +107,7 @@ Implementations of this specification do not have to implement all of the flows # OpenID for Verifiable Credential Issuance -The requirements for the Wallet and the Credential Issuer, unless specified otherwise: +Both the Wallet and the Credential Issuer: * 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). @@ -208,9 +208,8 @@ This is an example of a Wallet Instance Attestation: # OpenID for Verifiable Presentations profile for IETF SD-JWT VC over HTTPS -The requirements for the Wallet and the Verifier, unless specified otherwise: +Requirements for both the Wallet and the Verifier: - * 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]. @@ -238,8 +237,10 @@ The following requirements apply for both, the Wallet and the Verifier, unless s ## ISO mdoc specific requirements for OpenID for Verifiable Presentations over W3C Digital Credentials API +Requirements for both the Wallet and the Verifier: + * 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. + * 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. @@ -272,8 +273,10 @@ nonce = tstr ; using UTF-8 ## IETF SD-JWT VC specific requirements for OpenID for Verifiable Presentations over W3C Digital Credentials API - * The Credential Format identifier MUST be `dc+sd-jwt`. - * IETF SD-JWT VC Credential Format specific DCQL parameters as defined in Section 6.4.1. of [@!OIDF.OID4VP] MUST be used. +Requirements for both the Wallet and the Verifier: + + * The Credential Format identifier MUST be `dc+sd-jwt`. + * IETF SD-JWT VC Credential Format specific DCQL parameters as defined in Section 6.4.1 of [@!OIDF.OID4VP] MUST be used. # Self-Issued OP v2 From 58edeafb3cbd69d6d017c65569966e8716412c75 Mon Sep 17 00:00:00 2001 From: Kristina <52878547+Sakurann@users.noreply.github.com> Date: Thu, 12 Dec 2024 21:10:56 +0100 Subject: [PATCH 20/20] Apply suggestions from code review Co-authored-by: Oliver Terbu Co-authored-by: Daniel Fett --- ...-assurance-interoperability-profile-1_0.md | 38 +++++++++++-------- 1 file changed, 23 insertions(+), 15 deletions(-) diff --git a/openid4vc-high-assurance-interoperability-profile-1_0.md b/openid4vc-high-assurance-interoperability-profile-1_0.md index 9b1a55c..a6c6427 100644 --- a/openid4vc-high-assurance-interoperability-profile-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-1_0.md @@ -30,7 +30,7 @@ organization="SPRIND" .# Abstract -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]. +This document defines a profile of OpenID for Verifiable Credentials in combination with the credential formats IETF SD-JWT VC [@!I-D.ietf-oauth-sd-jwt-vc] and ISO mdoc [@!ISO.18013-5]. 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} @@ -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 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 the issuance of Credentials in both IETF SD-JWT VC and ISO mdoc [@ISO.18013-5] formats can be performed in the same transaction. +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 the issuance of Credentials in both IETF SD-JWT VC [@!I-D.ietf-oauth-sd-jwt-vc] and ISO mdoc [@ISO.18013-5] formats can be performed in the same transaction. A full list of the open standards used in this profile can be found in Overview of the Open Standards Requirements (reference). @@ -64,7 +64,7 @@ The following aspects are in scope of this interoperability profile: * ISO mdocs * Protocol for User Authentication by the Wallet at a Verifier (SIOP v2) * Profile of IETF SD-JWT VC that includes the following aspects - * Status Management of the Credentials, including revocation + * Status management of the Credentials, including revocation * Cryptographic Key Binding * Issuer key resolution * Issuer identification (as prerequisite for trust management) @@ -84,7 +84,7 @@ 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 OpenID4VCI to issue ISO mdocs is defined in ISO 23220-3. +* Profile of OpenID4VCI to issue ISO mdoc [@!ISO.18013-5] 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]. @@ -99,7 +99,7 @@ defined in [@ISO.18013-7]. For more details, also see Annex B.3 in [@!OIDF.OID4V This specification enables interoperable implementations 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 * Presentation of IETF SD-JWT VC using OpenID4VP over W3C Digital Credentials API * Presentation of ISO mdocs using OpenID4VP over W3C Digital Credentials API @@ -206,7 +206,7 @@ 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 IETF SD-JWT VC over HTTPS +# OpenID for Verifiable Presentations profile for IETF SD-JWT VC Requirements for both the Wallet and the Verifier: @@ -228,12 +228,12 @@ Requirements for both the Wallet and the Verifier: The following requirements apply for both, the Wallet and the Verifier, unless specified otherwise: * 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 as 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. + * The Wallet MUST support both signed and unsigned requests as defined in Annex A.3.1 and A.3.2 of [@!OIDF.OID4VP]. The Verifier MAY support signed requests, unsigned requests, or both. +* Wallet Invocation is done via the W3C Digital Credentials API or an equivalent platform API. Any other mechanism, including Custom URL schemes, MUST NOT be used. * Response Mode MUST be `dc_api.jwt`. The response MUST be encrypted. -* Specific requirements for the response encryption are tbd. +* Specific requirements for the response encryption are tbd (https://github.com/openid/oid4vc-haip/issues/131). * 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 + * tbd (https://github.com/openid/oid4vc-haip/issues/142) ## ISO mdoc specific requirements for OpenID for Verifiable Presentations over W3C Digital Credentials API @@ -242,16 +242,24 @@ Requirements for both the Wallet and the Verifier: * 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. + * 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 `DeviceResponse` instances. ### Session Transcript -The SessionTranscript as defined in Section 9.1.5.1 in [@ISO.18013-5] MUST 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 +* `DeviceEngagementBytes` MUST be null. +* `EReaderKeyBytes` MUST be null. -The Handover element is defined as following: +``` +SessionTranscript = [ + null, + null, + Handover +] +``` + +The `Handover` element is defined as following: ``` Handover = OID4VPDCAPIHandover