DCQL: express desired credential issuers

openid-4-verifiable-presentations-1_0.md

@@ -693,6 +693,16 @@ this object are defined per Credential Format. Examples of those are in (#sd_jwt
 no specific constraints are placed on the metadata or validity of the requested
 Credential.
 
+`accepted_issuers`:
+: OPTIONAL. A non-empty array of objects as defined in (#dcql_accepted_issuers) that
+specifies expected issuers or trust frameworks that an issuer belongs to, that the
+Verifier will accept. Every Credential returned by the Wallet SHOULD match at least
+one of the conditions present in the corresponding `accepted_issuers` array if present.
+
+Note that Relying Parties must verify that the issuer of a received presentation is
+trusted on their own and this feature mainly aims to help data minimization by not
+revealing information that would likely be rejected.
+
 `claims`:
 : OPTIONAL. A non-empty array of objects as defined in (#claims_query) that specifies
 claims in the requested Credential. Verifiers MUST NOT point to the same claim more than
@@ -705,6 +715,89 @@ The rules for selecting claims to send are defined in (#selecting_claims).
 
 Note that multiple Credential Queries in a request MAY request a presentation of the same Credential.
 
+### Accepted Issuer Query {#dcql_accepted_issuers}
+
+An Accepted Issuer Query is an object representing information that helps to identify an issuer
+or the trust framework that an issuer is belonging to. A Credential is identified as a match
+to an Accepted Issuer Query if it to matches with one of the provided values in one of the provided
+types. How exactly the matching works is defined for the different types below
+
+Note that explicit issuer matching can also be achieved using claim value matching for certain
+Credential formats (e.g., value matching the `iss` claim in an SD-JWT). The methods provided in
+accepted_issuers are more tailored towards matching trust frameworks and those that require more
+complex matching logic (e.g., certificate thumbprints).
+
+Each entry in `accepted_issuers` MUST be an object with the following properties:
+
+`type`:
+: REQUIRED. A string uniquely identifying the type of information about the issuer trust framework.
+Types defined by this specification are listed below.
+
+`values`:
+: REQUIRED. An array of strings, where each string (value) contains information specific to the
+used Accepted Issuer Query type that allows to identify an issuer, trust framework, or a federation that an
+issuer belongs to.
+
+Below are descriptions for the different Type Identifiers (string), the description on how to interpret
+and perform the matching logic for each provided value.
+
+#### Authority Key Identifier
+
+Type:
+: `"aki"`
+
+Value:
+: The base64url encoded Authority Key Identifier element as defined in Section 4.2.1.1 of [@!RFC5280].
+The raw byte representation of this element MUST match with the AuthorityKeyIdentifier element of an X.509
+certificate in the trust chain of a matching Credential.
+
+Below is a non-normative example of such an entry of type `aki`:
+```json
+{
+  "type": "aki",
+  "values": ["s9tIpPmhxdiuNkHMEWNpYim8S8Y"]
+}
+```
+
+#### ETSI Trusted List
+
+Type:
+: `"etsi_tl"`
+
+Value:
+: The identifier (can also be a URL) of a Trusted List as specified in ETSI TS 119 612 [@ETSI.TL].An ETSI
+Trusted List contains references to other Trusted Lists, creating a list of trusted lists, or entries
+for Trust Service Providers with corresponding service description and X.509 Certificates. The trust chain
+of a matching Credential MUST contain at least one X.509 Certificate that matches one of the entries of the
+Trusted List or its cascading Trusted Lists.
+
+Below is a non-normative example of such an entry of type `etsi_tl`:
+```json
+{
+  "type": "etsi_tl",
+  "values": ["https://lotl.example.com"]
+}
+```
+
+#### OpenID Federation
+
+Type:
+: `"openid_fed"`
+
+Value:
+: The `Entity Identifier` as defined in Section 1 of [@!OpenID.Federation] that is bound to
+an entity in an OpenID Federation System. While this Entity Identifier could be any entity in
+that ecosystem, this entity would usually have the Entity Configuration of a Trust Anchor.
+A valid trust path, including the given Entity Identifier, must be constructible from a matching credential.
+
+Below is a non-normative example of such an entry of type `openid_fed`: 
+```json
+{
+  "type": "openid_fed",
+  "values": ["https://trustanchor.example.com"]
+}
+```
+
 ## Credential Set Query {#credential_set_query}
 
 A Credential Set Query is an object representing a request for one or more credentials to satisfy
@@ -1850,6 +1943,16 @@ In the event that another component is invoked instead of the Wallet, the End-Us
         </front>
 </reference>
 
+<reference anchor="ETSI.TL" target="https://www.etsi.org/deliver/etsi_ts/119600_119699/119612/02.01.01_60/ts_119612v020101p.pdf">
+        <front>
+          <title>ETSI TS 119 612 V2.1.1 Electronic Signatures and Infrastructures (ESI); Trusted Lists </title>
+          <author>
+            <organization>European Telecommunications Standards Institute (ETSI)</organization>
+          </author>
+          <date year="2015"/>
+        </front>
+</reference>
+
 <reference anchor="BCP195" target="https://www.rfc-editor.org/info/bcp195">
         <front>
           <title>BCP195</title>
@@ -2806,7 +2909,8 @@ The technology described in this specification was made available from contribut
    [[ To be removed from the final specification ]]
 
    -25
-
+
+   * add `accepted_issuers` to DCQL
    * add language on client ID and nonce binding for ISO mdocs and W3C VCs
    * clarify the behavior is not to sign when authorization_signed_response_alg is omitted