Enable RP to convey the desired credential issuers to the Wallet

[martijnharing]

The ISO specification is considering adding a parameter to identify the supported issuers for the requested document. We should add this as an option to DCQL as well.

The definition for the parameter is mdoc specific so we should probably add it as an mdoc specific parameter to the claims query. It could have the following definition:

issuer_identifiers: this is an array of issuer_identifier. If present, the issuer of the returned mdoc has to be one of issuer_identifier to satisfy the request from the RP.
The format used to identify an issuing authority is the base64url encoded keyIdentifier of the AuthorityKeyIdentifier that’s referenced in one of the certificates in the x509 chain element in the IssuerAuth header of the mdoc.

[leecam]

Very supportive of issuer matching for both mdoc and SD-JWTs. This was discussed at IIW and I think the consensus was this is a feature we need to add to DCQL

[c2bo]

This would basically be value matching for an array of expected issuers (identifiers), right? Wouldn't it then be already possible by value matching the corresponding claim to an array of expected values?
I guess for mdoc, we would need to define the (virtual?) claim of an issuer identifier, if I understand correctly? That way we would not need to change anything, but define a virtual claim for mdoc that allows for matching using the normal DCQL syntax.

An example in SD-jWT would look like this:

{
  "credentials": [
    {
      "id": "my_credential",
      "format": "vc+sd-jwt",
      "meta": {
        "vct_values": [ "https://credentials.example.com/identity_credential" ]
      },
      "claims": [
        {
          "path": [ "iss" ],
          "values": [
            "https://example.gov",
            "https:/another-example.gov"
          ]
        },
        {
          "path": [ "last_name" ]
        },
        {
          "path": [ "first_name" ]
        }
      ]
    }
  ]
}

and mdoc could look like this

{
  "credentials": [
    {
      "id": "my_credential",
      "format": "mso_mdoc",
      "meta": {
        "doctype_value": "org.iso.7367.1.mVRC"
      },
      "claims": [
        {
          "namespace": "virtual",
          "claim_name": "issuer_identifier",
          "values": [
            "eyJh..",
            "eyAb.."
          ]
        },
        {
          "namespace": "org.iso.7367.1",
          "claim_name": "vehicle_holder"
        },
        {
          "namespace": "org.iso.18013.5.1",
          "claim_name": "first_name"
        }
      ]
    }
  ]
}

Not sure if this is a good syntax to signal the virtual claim, but this way no further parsing logic is necessary.

[Sakurann]

Agree that this is an important feature, not only in mdocs.

Also agree with Christian that this would already be possible since mdocs have issuing_authority claim, right?

we could do a small clarification PR, but I don't think any normative change is needed.

[martijnharing]

In the case of mdocs, the issuer selection is based on the AuthorityKeyIdentifier in one of the certificates in the header of the IssuerAuth structure (see a possible proposal with the definition in the first post of the issue), So it's not a claim (data element) of the credential directly.

Using the claim value matching approach does not seem a good fit for a number of reasons:

• It's not a claim in the credential, which the current value matching works with.
• Matching is based on an octet string, which is not supported by the current value matching approach.
• It's not a single value to match against, rather whether at least one of the certificates in the IssuerAuth header contains the requested value.

We can come up with special handling requirements for all of these items, but at that point we are not really using anylogic from of the claim value matching anymore.

[c2bo]

So if we pull issuer_identifier out of the normal DCQL query and into the format specific parts, it would look like this I guess?

{
  "credentials": [
    {
      "id": "my_credential",
      "format": "mso_mdoc",
      "meta": {
        "doctype_value": "org.iso.7367.1.mVRC"
        "issuer_identifiers": ["eyJh..", "eyAb.."]
      },
      "claims": [
        {
          "namespace": "org.iso.7367.1",
          "claim_name": "vehicle_holder"
        },
        {
          "namespace": "org.iso.18013.5.1",
          "claim_name": "first_name"
        }
      ]
    }
  ]
}

with the expected values of issuer_identifier being base64url encoded -> validation would be decoding into octet string and comparing along the cert chain if I understand correctly?

[paulbastian]

I would agree putting it into format specific meta. The claim matching is not the most secure option, as rogue issuers could still set any claim for iss. Matching to something from the cryptographic trust chain is the better option

[awoie]

I am in favor of putting it into mdoc meta as well as I mentioned it previously.

[martijnharing]

The specific solution could be:
issuer_identifiers: this is an array of issuer_identifier. If present, the issuer of the returned mdoc must be one of issuer_identifier to satisfy the request from the RP.
The format used to identify an issuing authority is the base64url encoded keyIdentifier of the AuthorityKeyIdentifier that’s referenced in one of the certificates in the x509 chain element in the IssuerAuth header of the mdoc.

I can open a PR for that if there is support on this direction.

[c2bo]

Sounds like a good idea to me and would fit to my example if we choose to convey this in "meta" -> "issuer_identifiers" if I understand correctly.

[Sakurann]

what do we do for the issuer matching for non-mdocs. I believe the solution should be symmetric. Do we introduce another iss_identifiers claim in meta for SD-JWTs? there are definitely SD-JWTs whose signing key is obtained using x5c header parameter. and if that the case, is a non-credential format specific claim better?

[awoie]

what do we do for the issuer matching for non-mdocs. I believe the solution should be symmetric. Do we introduce another iss_identifiers claim in meta for SD-JWTs? there are definitely SD-JWTs whose signing key is obtained using x5c header parameter. and if that the case, is a non-credential format specific claim better?

It could be as simple as iss value matching but this has a different quality than what is proposed for mdocs above. mdocs use a public key as the issuer identifier to match against any keys in X.509 certs along the X.509 chain.

Since the proposed mechanism is quite general, we could apply this mechanism to all credential formats (including SD-JWT VC) that are signed by keys whose public keys are published via X.509 cert chains.

However, for SD-JWT VC, it is probably more likely that folks will lean towards value matching based on the iss claim which is still an option if DCQL supports a general claim by value query.

[tlodderstedt]

I think the key question is how the desired set of issuers is determined. I see the following options:

1. by an identifier (like a Distinguished Name or an URL)
2. by a certificate value
3. by a public key value
4. indirectly by a CA certificate
5. indirectly by a Trusted List containing CA certificates
6. For SD-JWT, that could also be indirectly by a federation trust anchor or list of those.

I think 1-3 would work well with value matching. For 4-6 I'm not so sure.

Having said that, I believe 4-6 are the options needed for any large scale wallet ecosystem so we need to cater for them.

[c2bo]

Am I understanding you correct that

3. by a public key value

This would be directly the issuer public key?

4. indirectly by a CA certificate

This would be somewhere up in the trust chain?

Points 4 and 5 seem to be some kind of dependency where 5 would be a mechanism to convey a list of 4 -> basically just some kind of identifier that is internally resolved to an array of root certs?
For Federation, I assume the trust anchors are identified by URLs - so basically the same but not base64url encoded certs, but string identifiers that are found somewhere in the trust chain?

I tend to agree with Kristina that this mechanism seems to be more generic and it probably makes sense to make sure this works for every credential that supports some kind of certificate chain (or similar trust mechanism).

I would also agree with Torsten that it sounds like we really need support for this or growing ecosystems (with joining/leaving issuers) will be a pain.

[paulbastian]

Relying Parties may use the same mechanisms for the query as for the actual verification logic. Therefore we should promote mechanisms that are cryptographically verifiable, i.e. not spoofable identifiers.

[tlodderstedt]

WG Call 9.1.2025

• sense in the room is to support indirect scenarios as well
• WG needs to decide whether this is incorporated as DCQL feature or a dedicated new feature (sense in the session is it should be a dedicated DCQL feature - not value matching)

[hlozi]

Clarification as requested during the meeting: In the 18013-5 second edition CD text, the format of an IssuerIdentifier is the value of the AuthorityKeyIdentifier element of an X.509 certificate.
A Wallet is considered satisfies the request if one of the IssuerIdentifiers provided by the RP matches the AuthorityKeyIdentifier in one of the certificates present in the x5chain of the header of the IssuerAuth header of the MDOC.

[tlodderstedt]

As requested in the WG call, here is an explanation of how the trust chain validation will work in EUDIW context using the example of a PID (eID credential). The description is based on https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/arf/#6-trust-model.

The signing certificate of every PID provider must be related to a so-called "trusted list". A trusted Lists are a XML structure (standardized by ETSi https://www.etsi.org/deliver/etsi_ts/119600_119699/119612/02.02.01_60/ts_119612v020201p.pdf) that contains metadata about service providers including their x.509 certificates. So either the PID provider's certificate is directly contained in the trusted list or there is a x.509 trust chain from a certificate of a certification authority in the trusted list to the PID provider's certificate.

So once a RP receives a PID, it would check the certificate used to sign the PID against that list. As far as I understand, there could be multiple levels of trusted lists, e.g. one on the EU-level and one very every Member State.

That's how it works today for Qualified Trusted Service Providers (eIDAS v1/2014). There, the EU hosts the "EU Trusted List" that is composed from trusted lists maintained by the member states.

Here is EU Trusted List in machine processible form: https://ec.europa.eu/tools/lotl/eu-lotl.xml
And this is for users to play around: https://eidas.ec.europa.eu/efda/trust-services/browse/eidas/tls

[bc-pi]

Relying Parties may use the same mechanisms for the query as for the actual verification logic. Therefore we should promote mechanisms that are cryptographically verifiable, i.e. not spoofable identifiers.

Relying Parties absolutely have to fully validate the received credentials regardless of what they asked for and cannot ever rely on the wallet's application/evaluation of query for security proposes.

[hlozi]

Relying Parties absolutely have to fully validate the received credentials regardless of what they asked for and cannot ever rely on the wallet's application/evaluation of query for security proposes.

The issuer selection feature is not intended for security purposes. Instead, it serves as a signal to the wallet, prompting it to refrain from returning responses that the relying party cannot verify. However, as mentioned earlier, the relying party is still responsible for performing validation, regardless of the issuer selection.