DCQL: express desired credential issuers

[c2bo]

Closes #322

please re-review as discussed changes were applied:

• drop vical and x5t in this PR

Some next steps

• open the issues to potentially add vical and x5t later
• moving openid federation into a separate PR unless agreement on openid_fed is reached before thursday
• bikeshed the parameter name to the extent it does not impact the merging timelines too much

[lj-raidiam]

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?

[c2bo]

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?

[lj-raidiam]

Good point. In general it would be nice to make it more universal.

[c2bo]

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

[tlodderstedt]

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

[Sakurann]

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

[Sakurann]

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

[awoie]

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

[c2bo]

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.

[sloops77]

@c2bo what about permitting using DID's? Swiss EID & Ayra are planning to use OID4VC with DIDs and would benefit from this feature

[c2bo]

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

[tlodderstedt]

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

[sloops77]

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

I somehow ignored the first section that described using iss matching. I think perhaps the name should be changed from accepted_issuers to accepted_issuer_authorities or accepted_trust_anchors.

Alternatively I wonder if you considered doing something wider such as accepted_trust_frameworks. This sort of name could support a wider scope, more than simply authority matching, it could require a particular trustmark in OpenId Fed.

[c2bo]

I somehow ignored the first section that described using iss matching. I think perhaps the name should be changed from accepted_issuers to accepted_issuer_authorities or accepted_trust_anchors.

Alternatively I wonder if you considered doing something wider such as accepted_trust_frameworks. This sort of name could support a wider scope, more than simply authority matching, it could require a particular trustmark in OpenId Fed.

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 accepted_issuers, but happy to change if we can agree on a better name.

[TimoGlastra]

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)

[c2bo]

As discussed on last WG call: added a small note that references a new subsection in the privacy considerations that describes possible privacy implications depending on used mechanism (especially online lookup).

@martijnharing does this work for you?

[martijnharing]

As discussed on last WG call: added a small note that references a new subsection in the privacy considerations that describes possible privacy implications depending on used mechanism (especially online lookup).

@martijnharing does this work for you?

The text added mostly talks about benefits of different trust mechanisms in general, which is related to the issue we are discussing but not necessarily fully applicable in the context of this PR. The goal of the issuer selection mechanism is only to tell the wallet which credential issuers it accepts, that's a signal coming from the RP. There isn't really any security impact related to it, it's just there for privacy and ux reasons.

So while there may be trust systems that require online checks to be done in certain scenarios, for the specific scenario of telling the wallet which RPs it will accept, the RP can tell the wallet which credential issuers it trusts. Even if that lists lives online, the RP has to be in possession in it and it could therefore provide the (simplified version) of that list to the wallet.

Looking what this means for the proposed text, it says that:

The proposed text says "Generally speaking, a distinction can be made between self-contained mechanisms, where all information necessary to validate if a credential matches the request is already present in the Wallet and Verifier, and those mechanisms that require some form of online resolution."

My comment on this text would be that there is a difference for privacy and security purposes between the RP needing to call out for certain checks versus the wallet needing to call out for those checks (especially before user authentication). Ideally when possible we minimize the needs for the wallet to call out externally, more so than the need for the RP to do so.

[TimoGlastra]

While prototyping this, one consideration we found of keeping some credential issuer restrictions as claim queries and some using this new syntax is that it can become hard to combine the two. It won't be possible to request a credential that is either issued by this did, or by this x509 certificate chain (aki). It will be possible however to request a credential issued by an openid federation OR an x509 certificate chain (aki). This puts a disadvantage on DIDs and I'd prefer it to be queryable using the customized syntax as well.

[Sakurann]

@TimoGlastra

It won't be possible to request a credential that is either issued by this did, or by this x509 certificate chain (aki). It will be possible however to request a credential issued by an openid federation OR an x509 certificate chain (aki).

I think that issue is easy to solve by simply defining trusted_authorities of type did - either in OpenID4VP directly or its profile. Please feel free to open an issue on this - it would be v1.1 - and open a PR later

[Sakurann]

WG discussion

• Martijn's biggest concern is about using URLs being a privacy issue
  • privacy concern is that the URL is being called without user consent, and gives a signal to RPs/issuers
• for ETSI trust list, third party is hosting the URL, so issuers and RPs would not get a signal.
  • could pass a trust list by value..?
• agreement that with DC API, URLs make less sense because fetching within the matcher does not work (at least for Android)

Next step: Christian to add one more paragraph in privacy considerations about "the wallet should fetch the URL only when the wallet should have a way to verify that the url in the request is legitimate (not just blindly trust the value given by the RP). when trusted third party is hosting that URL, issuers and RPs would not get a signal, so the privacy concern is mitigated.

privacy concern is also mitigated when the wallet is not fetching the URL, because URL is merely an identifier and is not being fetched by the wallet."

Martijn to open an issue to dig deeper, if needed.

[lj-raidiam]

• for ETSI trust list, third party is hosting the URL, so issuers and RPs would not get a signal.

In most cases it will also be true for the federation.

@martijnharing

Next step: Christian to add one more paragraph in privacy considerations about "the wallet should fetch the URL only when the wallet should have a way to verify that the url in the request is legitimate (not just blindly trust the value given by the RP). when trusted third party is hosting that URL, issuers and RPs would not get a signal, so the privacy concern is mitigated.

Makes sense.