DCQL: express desired credential issuers #393
Conversation
c2bo
changed the title
| : 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. | ||
| The trust chain of a matching credential MUST contain the given Entity Identifier. |
There was a problem hiding this comment.
| The trust chain of a matching credential MUST contain the given Entity Identifier. | |
| The trust chain of a matching credential MUST contain the Entity Configuration issued by the Entity identified by the given Entity Identifier. |
There was a problem hiding this comment.
There is no direct use case for that but logically we should also consider including option to use intermediary ids. Any thoughts?
There was a problem hiding this comment.
Sounds reasonable to me with my limited knowledge of OIDF, @selfissued, @peppelinux ?
There was a problem hiding this comment.
With the disclaimer that I'm no expert in OIDF, I believe there is no such thing as "the trust chain" for a given credential. There could be multiple trust roots that a credential could chain up to (especially assuming that roots will cross-certify each other as trusted peers, e.g. in the EU). So I would recommend something like "A valid trust path, terminating at the given Entity Identifier, must be constructible from a matching credential".
There was a problem hiding this comment.
Agreed that trust chain doesn't seem to be the best wording here. I am a bit hesitant with the word "terminating" as it sounds like we want to allow intermediate entities and terminating could be interpreted as reaching a Trust Anchor?
Would this work for you @lj-raidiam , @balfanz
| The trust chain of a matching credential MUST contain the given Entity Identifier. | |
| A valid trust path, reaching the given Entity Identifier, must be constructible from a matching credential. |
There was a problem hiding this comment.
I'm curious how the processing of this would work. Knowing if you can build a chain including the requested entity id often involves a (complicated) resolving process. As @balfanz pointed out, multiple paths could exist, so you'd either have to:
- store (a subset of) the possible trust chains with the credential, so you can perform this offline
- resolve the trust chain dynamically to match (this doesn't seem like a good approach, credential matching should be performed locally IMO).
There was a problem hiding this comment.
Reaching would still suggest an end, maybe including works?
| The trust chain of a matching credential MUST contain the given Entity Identifier. | |
| A valid trust path, including the given Entity Identifier, must be constructible from a matching credential. |
There was a problem hiding this comment.
I'm curious how the processing of this would work. Knowing if you can build a chain including the requested entity id often involves a (complicated) resolving process. As @balfanz pointed out, multiple paths could exist, so you'd either have to:
- store (a subset of) the possible trust chains with the credential, so you can perform this offline
- resolve the trust chain dynamically to match (this doesn't seem like a good approach, credential matching should be performed locally IMO).
Yes, wallets will have to store it for all credentials to do the filtering. Perhaps in more complex case (like two paths) this filtering will not be ideal. Verifiers will have a harder work to do as they will have to resolve it dynamically in most cases.
| 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. | ||
|
|
||
| TODO: Do we need to specify more like Entity Type for matching? |
There was a problem hiding this comment.
If OpenID Federation 4 Wallet Architectures is supported the issuer could be only https://openid.net/specs/openid-federation-wallet-1_0.html#section-6.2
@peppelinux any thoughts?
|
|
||
| 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 |
There was a problem hiding this comment.
We could change OpenID Federation System to a federation or an ecosystem or something along these lines.
Co-authored-by: lj-raidiam <[email protected]>
|
|
||
| Value: | ||
| : The identifier (can also be a URL) of a Trusted List as specified in ETSI TS 119 612. | ||
| TODO: How to express restrictions within that TL? e.g., filtering by service type? |
There was a problem hiding this comment.
My biggest question here is if the expectation is for a specific trusted list (of lists) to only include one type (e.g., all PID issuers), or if we will have bigger lists where we need to filter within that one list for different types.
I started reading ARF annex 2 for PID issuance and currently my understanding would be that for the PID we have a special list of PID Providers (so no filtering necessary). Is that correct and are we fine to start with the assumption that no further filtering is necessary here?
@babisRoutis are you be any chance able to provide a bit more information on this?
There was a problem hiding this comment.
Good point. In general it would be nice to make it more universal.
…penid/OpenID4VP into 322-desired-credential-issuers-in-dcql
| #### 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 | ||
| 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 | ||
| 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"] | ||
| } | ||
| ``` |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
I agree. The current revision is a good starting point. Implementation experience will show what is needed on top.
| } | ||
| ``` | ||
|
|
||
| #### Authority Key Identifier |
There was a problem hiding this comment.
ISO feedback. less options the better. AKI alone is probably sufficient. AKI meets ISO requirement.
There was a problem hiding this comment.
Then we should consider dropping VICAL.
| } | ||
| ``` | ||
|
|
||
| #### Verified Issuer Certificate Authority List (VICAL) |
There was a problem hiding this comment.
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
| 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 |
There was a problem hiding this comment.
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..?
| #### 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"] | ||
| } | ||
| ``` | ||
|
|
There was a problem hiding this comment.
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.
| #### 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"] | |
| } | |
| ``` |
There was a problem hiding this comment.
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.
Co-authored-by: Michael B. Jones <[email protected]>
|
@c2bo what about permitting using DID's? Swiss EID & Ayra are planning to use OID4VC with DIDs and would benefit from this feature |
I thought about that but my assumption was that DIDs would work pretty well with value matching. |
| } | ||
| ``` | ||
|
|
||
| #### Authority Key Identifier |
There was a problem hiding this comment.
Then we should consider dropping VICAL.
| #### 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 | ||
| 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 | ||
| 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"] | ||
| } | ||
| ``` |
There was a problem hiding this comment.
I agree. The current revision is a good starting point. Implementation experience will show what is needed on top.
I somehow ignored the first section that described using Alternatively I wonder if you considered doing something wider such as |
Fair point on the naming. We currently have a bit of a mix with more direct matching like AKI and the broader methods like etsi trusted lists and openid federation. That is why I went with |
…penid/OpenID4VP into 322-desired-credential-issuers-in-dcql
There was a problem hiding this comment.
I think adding did as a supported issuer type here makes sense as well, since DIDs are also allowed as client_id_scheme, and ETSI trust list is also included (which I'm not sure belongs in the base spec if we follow the reasoning why DIDs was proposed to be removed)
Co-authored-by: Timo Glastra <[email protected]>
Do you think adding a section here would be beneficial over value matching on the issuer (e.g., iss = did:xyz:abcdef)? |
Co-authored-by: Timo Glastra <[email protected]>
Yeah I guess that would work fine. Thought of a few things and only anoncreds seems like it could be an issue:
|
|
Questions for the working group:
I would also propose to create a small PR in HAIP mandating only support for AKI, which would be in line with the key resolution parts of HAIP etc. |
|
I'm against including any option that uses a URL as part of the mechanism to determine which issuers are supported when the DC API is used. An explicit design consideration for the use of the DC API is that there is no necessity for any of the components (browser, os, wallet etc) to make an external call (at the very least before user consent) and we made significant efforts in the design to ensure that this is the case. |
I understand the concern, but the current wording only requires an ID (which could also be a URL - I can remove that remark). We have existing systems like the EU Trusted Lists that are usually referenced as the URL of the root list (https://ec.europa.eu/tools/lotl/eu-lotl.xml). All systems I've seen do not actively poll/resolve that URL, but in theory it is still provided via those signed XML files with their root at that URL and the URL seems to be a decent identifier. |
There was a problem hiding this comment.
Before continuing the revision I ask to further clarify the scope of this parameter and this PR, since it seems about the accepted issuers but contains information that mixes trust evaluation mechanisms and trust frameworks (that are separate thing, even if they should be complementary. Consider that a trust evaluation mechanism can live without a properly defined trust framework).
My comments aims to facilitate this change, even if in an non exhaustive way.
| `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. | ||
|
|
There was a problem hiding this comment.
| `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
| 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. |
There was a problem hiding this comment.
| 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. | |
| An Accepted Issuer Query is an object representing information that identify one or more Credential Issuers. | |
| A Credential matches an Accepted Issuer Query if it aligns at least its Credential Issuer and the Credential Issuer configures the Credential as supported (eg: `iss` and `vct` for SD-JWT). Different Credential Types may use different matching approaches. | |
| Each `accepted_issuers` object MUST have the following members: | |
| `credential_issuer`: | |
| : REQUIRED. A string uniquely identifying the Credential Issuer. | |
| `trust_evaluations_supported`: | |
| : REQUIRED. An array of strings, uniquely identifying the type of information about the trust evaluation mechanism the Credential Issuer MUST support. | |
| `trust_frameworks_supported`: | |
| : OPTIONAL. An array of strings, where each string (value) contains information specific to the | |
| supported trust framework the Credential Issuer MUST belong to, to be considered a valid Credential Issuer. | |
| Below are descriptions for the different Type Identifiers (string), the description on how to interpret | |
| and perform the matching logic for each provided value. |
There was a problem hiding this comment.
I don't think your proposal would work with the current scope of the PR:
- Part of the problem initially discussed in the issue was that not every issuer is easily identified by a string (see the Authority Key Identifier discussion)
- The discussion in the issue basically spanned 2 problems:
- Direct issuer matching -> This will be done by value matching (out of scope here) unless impossible (AKI)
- Expressing requirements about the trust chain/path -> Instead of directly identifying the issuer, expressing some expected properties/entities in the trust chain
This PR mainly covers the second part - describing some requirements that the trust chain/path of a credential has to fulfil. I think some of the confusion stems from the rather unfitting name "accepted_issuers"?
|
I support @lj-raidiam's and @peppelinux's change suggestions. |
If the URL is only used as an identifier and it's prohibited to actually use it as a URL I agree there aren't any direct privacy concerns. But from a design perspective it's a bit risky to rely on the fact that implementers have to realize that they are prohibited from using the URL to retrieve the list, especially if they don't have the contents of what the URL is referring to but still they are prohibited from using it to retrieve the list. |
|
My take on WG discussion:
|
|
WG discussion:
|
Closes #322