Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

DCQL: express desired credential issuers #393

Open
wants to merge 15 commits into
base: main
Choose a base branch
from
Open
Changes from 6 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
142 changes: 142 additions & 0 deletions openid-4-verifiable-presentations-1_0.md
Original file line number Diff line number Diff line change
Expand Up @@ -688,6 +688,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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`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.
`accepted_issuers`:
: OPTIONAL. A non-empty array of objects as defined in (#dcql_accepted_issuers) that
specifies expected Credential Issuers that the
Verifier accepts. Every Credential returned by the Wallet SHOULD match at least
one of the conditions present in the corresponding `accepted_issuers` array if present.
Relying Parties using this parameter MUST ensure that the Credential Issuers specified are both active and trusted at the time of the query.

I would not mix trust frameworks identifiers with credential identifiers in the same parameter

`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
Expand All @@ -700,6 +710,128 @@ 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.
Possible types are defined below.
c2bo marked this conversation as resolved.
Show resolved Hide resolved

`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.

#### X.509 Thumbprint
Copy link
Collaborator

@Sakurann Sakurann Jan 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reasoning to introduce this was for the CA that do not have AKIs. CAB forum mandates AKIs, but not all CAs are web certificates, so those might not have AKIs - not sure how many of those certs don't have AKIs..?


Type:
: `"x5t#S256"`

Value:
: The base64url encoded SHA-256 digest (a.k.a. thumbprint, fingerprint) of the DER encoding of an X.509
certificate as defined in Section 4.1.8 of [@!RFC7515]. This thumbprint MUST match with the thumbprint
of an X.509 certificate in the trust chain of the Credential.

Below is a non-normative example of such an entry of type `x5t#S256`:
```json
{
"type": "x5t#S256",
"values": ["455943cf819425761d1f950263ebf54755d8d684c25535943976f488bc79d23b"]
}
```

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest removing X.509 thumbprint because it is less useful than aki and doesn't have any benefit over aki. It has actually a couple of downsides like having issues with re-issued certificates.

Suggested change
#### X.509 Thumbprint
Type:
: `"x5t#S256"`
Value:
: The base64url encoded SHA-256 digest (a.k.a. thumbprint, fingerprint) of the DER encoding of an X.509
certificate as defined in Section 4.1.8 of [@!RFC7515]. This thumbprint MUST match with the thumbprint
of an X.509 certificate in the trust chain of the Credential.
Below is a non-normative example of such an entry of type `x5t#S256`:
```json
{
"type": "x5t#S256",
"values": ["455943cf819425761d1f950263ebf54755d8d684c25535943976f488bc79d23b"]
}
```

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The 2 biggest reasons why I chose to include it in the initial proposal was

  • x5t is somewhat commonly used in the oauth world -> keep the choices consistent
  • AuthoriyKeyIdentifier is an extension and I was not sure if every ecosystem that would want to use AKI.

That said, I am happy to remove it if everyone can use / is happy with AKI. Less choices is always a good thing. It would also be easy to re-introduce x5t later on.

#### Authority Key Identifier
c2bo marked this conversation as resolved.
Show resolved Hide resolved

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"]
}
```

#### Verified Issuer Certificate Authority List (VICAL)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DCP WG discussion. leaning to keep it in OpenID4VP because value is not defined as a URL, but an identifier that does not have to be resovled


Type:
: `"vical"`

Value:
: The identifier (can also be a URL) of a Verified Issuer Certificate Authority List (VICAL) as specified in
[@ISO.18013-5]. The VICAL contains a list of Issuing Authority Certificate Authorities (IACA), that provide
DER encoded X.509 Certificates and corresponding allowed document types (an array of DocType identifiers).
This Type MUST only be used in combination with Credentials of the Credential Format mdoc. The trust chain
of a matching Credential MUST contain at last one X.509 Certificate entry in the IACAs and the allowed
DocTypes of the corresponding IACA entry MUST match with the doctype of the Credential.

Below is a non-normative example of such an entry of type `vical`:
```json
{
"type": "vical",
"values": ["https://vical.example.com"]
}
```

#### 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 trustedf lists, or entries
c2bo marked this conversation as resolved.
Show resolved Hide resolved
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 entires of the
c2bo marked this conversation as resolved.
Show resolved Hide resolved
Trusted List or its cascading Trusted Lists.

Below is a non-normative example of such an entry of type `etsi_tl`:
c2bo marked this conversation as resolved.
Show resolved Hide resolved
```json
{
"type": "etsi_tl",
"values": ["https://lotl.example.com"]
}
```
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might be missing something but it seems to me that how exactly the PID Issuer trusted list (or list of lists) will look like is currently not 100% clear- In that case I would propose to leave the ETSI TL as is (without more complex matching logic) and open an issue to revisit before going final

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. The current revision is a good starting point. Implementation experience will show what is needed on top.


#### 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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could change OpenID Federation System to a federation or an ecosystem or something along these lines.

c2bo marked this conversation as resolved.
Show resolved Hide resolved
that ecosystem, this entity would usually have the Entity Configuration of a Trust Anchor.
The trust chain of a matching credential MUST contain the given Entity Identifier.
c2bo marked this conversation as resolved.
Show resolved Hide resolved

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
Expand Down Expand Up @@ -1844,6 +1976,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>
Expand Down