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 with my limited knowledge of OIDF, @selfissued, @peppelinux ?
| 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?
…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
Closes #322
Needs a bit more work, but I thought it is probably worth it to have this draft PR visible for initial discussions