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.