From 0a44d1d4cc50ff4b27106115d1a08a9613ea1c31 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 2 Oct 2026 08:46:21 +0200 Subject: [PATCH 1/3] add Selective Disclosure and Selectively Disclosable Claim --- 1.1/openid-4-verifiable-presentations-1_1.md | 24 ++++++++++++++++---- 1 file changed, 19 insertions(+), 5 deletions(-) diff --git a/1.1/openid-4-verifiable-presentations-1_1.md b/1.1/openid-4-verifiable-presentations-1_1.md index d8b40edd..fa29be9c 100644 --- a/1.1/openid-4-verifiable-presentations-1_1.md +++ b/1.1/openid-4-verifiable-presentations-1_1.md @@ -122,6 +122,12 @@ Origin: Presentation: : Data that is presented to a specific Verifier, derived from a Credential. In this specification, Presentations are usually Verifiable Presentations including Holder Binding (as defined below), but may also be Presentations without Holder Binding (discussed in (#nkb-credentials)). +Selective Disclosure: +: The ability of the Holder to present only a subset of the claims contained in a Credential to a Verifier, without revealing the other claims contained in that Credential. See (#selective-disclosure) for privacy considerations. + +Selectively Disclosable Claim: +: A claim that is only included in a Presentation if it was explicitly requested by the Verifier. Claims that are not selectively disclosable are always included in a Presentation of the Credential containing them, regardless of whether they were requested. Which claims are selectively disclosable depends on the Credential Format and on the Credential itself. + VP Token: : An artifact containing one or more Presentations returned as a response to an Authorization Request. The structure of VP Tokens is defined in (#response-parameters). @@ -925,20 +931,21 @@ When conversion according to these rules is not clearly defined, behavior is out The following section describes the logic that applies for selecting claims and for selecting credentials. -For formats supporting selective disclosure, these rules support selecting a minimal +For formats supporting Selective Disclosure, these rules support selecting a minimal dataset to fulfill the Verifier's request in a privacy-friendly manner (see (#privacy-considerations) for additional considerations). Wallets MUST NOT send -selectively disclosable claims that have not been selected according to the rules below. +Selectively Disclosable Claims that have not been selected according to the rules below. A single Presentation of a Credential MAY contain more than the claims selected in the particular DCQL Credential Query if the same Credential is selected with the additional claims in a separate Credential Query in the same request, or the additional claims are -not selectively disclosable. +not Selectively Disclosable Claims. Which claims are Selectively Disclosable Claims for a +particular Credential Format is defined in (#format_specific_parameters). ### Selecting Claims {#selecting_claims} The following rules apply for selecting claims via `claims` and `claim_sets`: -- If `claims` is absent, the Verifier is requesting no claims that are selectively disclosable; the Wallet MUST +- If `claims` is absent, the Verifier is requesting no Selectively Disclosable Claims; the Wallet MUST return only the claims that are mandatory to present (e.g., SD-JWT and Key Binding JWT for a Credential of format IETF SD-JWT VC). - If `claims` is present, but `claim_sets` is absent, @@ -981,7 +988,7 @@ deviate. Non-exhaustive examples of such reasons are: If the Wallet cannot deliver all claims requested by the Verifier according to these rules, it MUST NOT return the respective Credential. -For Credential Formats that do not support selective disclosure, the case of both `claims` +For Credential Formats that do not support Selective Disclosure, the case of both `claims` and `claim_sets` being absent is interpreted as requesting a presentation of the "full credential" since all claims are mandatory to present. @@ -2917,6 +2924,8 @@ The following is a non-normative example of the Verifiable Presentation in the ` 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] 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. +Every data element in an mdoc, identified by its `NameSpace` and `DataElementIdentifier`, is a Selectively Disclosable Claim. This applies both to data elements returned in the `IssuerSigned` structure (i.e., in `IssuerNameSpaces`) and to data elements returned in the `DeviceSigned` structure (i.e., in `DeviceNameSpaces`) [@ISO.18013-5]. Consequently, the Wallet MUST NOT include any data element in either structure that has not been selected according to the rules in (#dcql_query_lang_processing_rules). + The Credential Format Identifier for Credentials in the mdoc format is `mso_mdoc`. ### Transaction Data @@ -2925,6 +2934,8 @@ It is RECOMMENDED that each transaction data type defines a data element (`NameS Some document types support some transaction data ((#transaction_data)) to be protected using mdoc authentication, as part of the `DeviceSigned` data structure [@ISO.18013-5]. In those cases, the specifications of these document types include which transaction data types are supported, and the issuer includes the relevant data elements in the `KeyAuthorizations`. If a Wallet receives a request with a `transaction_data` type whose data element is unauthorized, the Wallet MUST reject the request due to an unsupported transaction data type. +Since data elements in the `DeviceSigned` structure are Selectively Disclosable Claims (see (#mdocs_sd_claims)), a Verifier requesting transaction data that is returned as a data element in the `DeviceSigned` structure MUST include a Claims Query for that data element in the respective Credential Query. + ### Metadata The `vp_formats_supported` parameter of the Verifier metadata or Wallet metadata MUST have the Credential Format Identifier as a key, and the value MUST be an object consisting of the following name/value pairs: @@ -3254,6 +3265,8 @@ CBOR diagnostic: This section defines how Credentials complying with [@!I-D.ietf-oauth-sd-jwt-vc] can be presented to the Verifier using this specification. +A claim (including an array element) is a Selectively Disclosable Claim if it is contained in a Disclosure as defined in [@!I-D.ietf-oauth-selective-disclosure-jwt]. When a Selectively Disclosable Claim nested in a selectively disclosable object or array is selected, the Disclosures of all parent objects or arrays of that claim are necessary to process it and are therefore also included in the Presentation, as described in [@!I-D.ietf-oauth-selective-disclosure-jwt]. Claims that are contained in plaintext in the Issuer-signed JWT are not Selectively Disclosable Claims and are always included in a Presentation. + If `require_cryptographic_holder_binding` is set to `true` in the Credential Query, the Wallet MUST return an SD-JWT [@!I-D.ietf-oauth-selective-disclosure-jwt] with a Key Binding JWT (SD-JWT+KB) as the Verifiable Presentation. SD-JWTs that do not support Holder Binding (i.e., do not have a `cnf` Claim) cannot be returned in this case. If `require_cryptographic_holder_binding` is set to `false`, an SD-JWT without the Key Binding JWT MAY be returned. @@ -3769,3 +3782,4 @@ The technology described in this specification was made available from contribut * add security considerations on untrusted input * Clarify `dc+sd-jwt` presentations use the compact serialized SD-JWT format * fix inconsistency on the JAR fallback from post to get if unsupported + * Define the terms Selective Disclosure and Selectively Disclosable Claim and add Credential Format specific rules on which claims are selectively disclosable From 0cef52383ac66cb70d2a2ca402fcff98b34a8fa2 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 2 Oct 2026 08:53:12 +0200 Subject: [PATCH 2/3] add w3c --- 1.1/openid-4-verifiable-presentations-1_1.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/1.1/openid-4-verifiable-presentations-1_1.md b/1.1/openid-4-verifiable-presentations-1_1.md index fa29be9c..06983a12 100644 --- a/1.1/openid-4-verifiable-presentations-1_1.md +++ b/1.1/openid-4-verifiable-presentations-1_1.md @@ -2751,6 +2751,8 @@ OpenID for Verifiable Presentations is Credential Format agnostic, i.e., it is d The following sections define the Credential Format specific parameters and rules for W3C Verifiable Credentials compliant to the [@VC_DATA] specification and for W3C Verifiable Presentations of such Credentials. +Credentials with the Credential Format Identifier `jwt_vc_json` do not contain Selectively Disclosable Claims. For Credentials with the Credential Format Identifier `ldp_vc`, which claims are Selectively Disclosable Claims depends on the Data Integrity cryptosuite [@VC_DATA_INTEGRITY] used. + If `require_cryptographic_holder_binding` is set to `true` in the Credential Query, the Wallet MUST return a Verifiable Presentation of a Verifiable Credential. If set to `false`, a Verifiable Credential without Holder Binding MUST be returned, i.e., the Wallet includes the Verifiable Credential itself directly in the VP Token, without wrapping it in a Verifiable Presentation. ### Parameters in the `meta` parameter in Credential Query @@ -2934,7 +2936,7 @@ It is RECOMMENDED that each transaction data type defines a data element (`NameS Some document types support some transaction data ((#transaction_data)) to be protected using mdoc authentication, as part of the `DeviceSigned` data structure [@ISO.18013-5]. In those cases, the specifications of these document types include which transaction data types are supported, and the issuer includes the relevant data elements in the `KeyAuthorizations`. If a Wallet receives a request with a `transaction_data` type whose data element is unauthorized, the Wallet MUST reject the request due to an unsupported transaction data type. -Since data elements in the `DeviceSigned` structure are Selectively Disclosable Claims (see (#mdocs_sd_claims)), a Verifier requesting transaction data that is returned as a data element in the `DeviceSigned` structure MUST include a Claims Query for that data element in the respective Credential Query. +Since data elements in the `DeviceSigned` structure are Selectively Disclosable Claims (see (#mdocs)), a Verifier requesting transaction data that is returned as a data element in the `DeviceSigned` structure MUST include a Claims Query for that data element in the respective Credential Query. ### Metadata From ac5d9bce4356f5f470dc7c63e2c781f2a4f369c3 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 2 Oct 2026 08:54:37 +0200 Subject: [PATCH 3/3] Apply suggestion from @paulbastian --- 1.1/openid-4-verifiable-presentations-1_1.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/1.1/openid-4-verifiable-presentations-1_1.md b/1.1/openid-4-verifiable-presentations-1_1.md index 06983a12..5ec66436 100644 --- a/1.1/openid-4-verifiable-presentations-1_1.md +++ b/1.1/openid-4-verifiable-presentations-1_1.md @@ -2936,8 +2936,6 @@ It is RECOMMENDED that each transaction data type defines a data element (`NameS Some document types support some transaction data ((#transaction_data)) to be protected using mdoc authentication, as part of the `DeviceSigned` data structure [@ISO.18013-5]. In those cases, the specifications of these document types include which transaction data types are supported, and the issuer includes the relevant data elements in the `KeyAuthorizations`. If a Wallet receives a request with a `transaction_data` type whose data element is unauthorized, the Wallet MUST reject the request due to an unsupported transaction data type. -Since data elements in the `DeviceSigned` structure are Selectively Disclosable Claims (see (#mdocs)), a Verifier requesting transaction data that is returned as a data element in the `DeviceSigned` structure MUST include a Claims Query for that data element in the respective Credential Query. - ### Metadata The `vp_formats_supported` parameter of the Verifier metadata or Wallet metadata MUST have the Credential Format Identifier as a key, and the value MUST be an object consisting of the following name/value pairs: