Add attachments in the presentation request

[cre8]

The Verifier Attestation JWT is good for authentication, but limited in further usage. Current requirements from the Implementing Acts require that the Relying Party need to present a so called Registration Certificate, where the intended use is attested by the Wallet-Relying Party Registrar. To avoid requests from the wallet to the registrar, the Relying Party should be able to attach this certificate to the presentation request.

The request includes a new credentials attribute, that allows to attach
certificates like registration and authorization certificates.

• type: STRING, media type of the attached credential, helping to parse the credential by the Wallet. The value has to be registered in the IANA media types registry.
• data: ANY, content of the credential. Will be parsed by the Wallet based on the type.
• credentialsMatch: STRING[], when the provided certificate is used for authorization, it will list the credential ids from the dcql_query.

{
  "x5c": ["mcnwmx...."], certificate to prove the signature
  "typ": "JWT",
  "alg": "ES256"
}
.
{
  "response_type":"vp_token",
  "client_id":"x509_san_dns:client.example.org",
  "response_mode":"direct_post",
  "dcql_query":{
    "credentials":[
      {
        "id":"my_credential",
        "format":"vc+sd-jwt",
        "meta":{
          "vct_values":[
            "https://credentials.example.com/identity_credential"
          ]
        },
        "claims":[
          {
            "path":[
              "last_name"
            ]
          },
          {
            "path":[
              "first_name"
            ]
          },
          {
            "path":[
              "address",
              "street_address"
            ]
          }
        ]
      }
    ]
  },
  "credentials":[
    {
      "type:" "jose",
      "data": "base64-encoded-registrationCertificate-jws"
    },
    {
      "type:" "jose",
      "data": "base64-encoded-authorizationCertificate-jws",
      "credentialsMatch": ["my_credential"]
    }
  ]
}.ejsdbwjhsbs

[tlodderstedt]

@cre8

Is the "type" related to OID4VC credential formats?
What is the semantics of "credentialsMatch"? In the description it states "when the provided certificate is used for authorization". Isn' that the purpose of the whole mechanism?

[tlodderstedt]

@cre8 isn't a further use case for this feature to provide attestations used to prove to the wallet certain role assignments or permissions in order to fulfill issuer defined policies. For example, a credential issuer might require the RP to be a certified payment service provider under PSD2 to get access to the respective credential. The attachment parameter could be used to pass the RP's PSD2 certificate.

[cre8]

@cre8

Is the "type" related to OID4VC credential formats? What is the semantics of "credentialsMatch"? In the description it states "when the provided certificate is used for authorization". Isn' that the purpose of the whole mechanism?

No, since you need pass more information like a status list, CRL, etc that is required by the Wallet to validate anything without requesting any external service that could leak privacy information. So the type field is a hint for the wallet how to decode or proceed with the passed information, like also a PSD2 certificate.

Based on @danielfett feedback using the iana media types would be a good fit for this.

[cre8]

ARF is also referencing that OID4VP needs to have such functionality.

I see no breaking change for the existing spec, so it's fine to treat it as an extension.

[cre8]

More insights are in the German Architecture Concept giving examples.

Two examples of attestation that need to be passed:

• Registration Certificate
• Authorization Certificate

There is no requirements of the attachment how binding is implemented. If it has no binding, claimed bound or bound via signature is not relevant for the extension, but has to be defined by the use case using it.

[Sakurann]

WG discussion

• feature and requirements makes sense.
• where to put this:
  • one suggestion to put it in client_metadata.
  • alternative would be to put it in the signature header of the JWS request. (currently a preferred option)
    • putting into the header would also help with multi-RP PR Add Multi RP Credentials/Authentication capability #308.
• in terms of the payload:
  • pick another parameter name than credential for top-level parameter. (as good as transaction_data)
  • type (another suggestion was format): the question on how do we deal with different ecosystems came up. might be worth considering this be closer to a type in transaction data and not just a media type.
  • do we need credentialsMatch? looks like we do.
    • precedent we have is credential_ids in transaction_data
  • data - ok
• what is the expected behavior when the wallet does not understand this parameter?
  • current expectation is "The Wallet MUST ignore any unrecognized parameters, other than the transaction_data parameter. the wallets that do not support transaction_data parameter MUST reject requests that contain it".
  • feels like this is closer to transaction_data, because the wallet should not return the credential if it cannot validate this parameter.

[tlodderstedt]

@Sakurann
What would be the advantage of putting it into the signature header?
What does "putting into the header would also help with multi-RP PR" mean?

what is the expected behavior when the wallet does not understand this parameter?
If the wallet ignores the parameter, it does not get the data to validate the disclosure policy, so it should either ask the user to disclose the data or fail.

[c2bo]

If we have requests from multiple trust frameworks represented by different client id schemes, we likely would also have other kind of credentials attached (conveying registration, policies etc.) that belong to these different trust ecosystem. Generally speaking, there seems to be some level of binding between trust ecosystem (client id scheme) and these kind of attachments about registration/authorization/policies.

From that perspective, it seems to make sense to find a mechanism to convey these attachments in a form that they

• can be provided differently depending on the different client id schemes in a multi-rp presentation
• have clear binding to the credentials in the DCQL query that they are meant for

The second one seems to be pretty straight forward with the current proposal of providing matching credential_ids.

Would it make sense to convey credentials (or whatever name we end up with) in client_metadata and allow for client_metadata in both, the protected header and the payload in the multi-rp case?

[cre8]

I think the protected header is fine, since you will find ALL information about Relying Party Authentication and Authorization in one place and you are able to add different ones when needed.

when following this approach, the type field is more relevant for the ecosystem, rather for general parsing by the Wallet.

So in case of EUDI Wallet, one could be type=RegistrationCertficiate. Another trust eco system can ignore this, but the Wallet knows how to parse the value in the data field (also including decoding, etc.). I would not suggest to set the type as a key, because in some situations you need to pass multiple objects of the same type.

So the JSON serialized JWS AuthReq would look like:

{
  "payload": {
    "response_type": "vp_token",
    "client_id": "x509_san_dns:client.example.org",
    "response_mode": "direct_post",
    "dcql_query": {
      "credentials": [
        {
          "id": "my_credential",
          "format": "vc+sd-jwt",
          "meta": {
            "vct_values": [
              "https://credentials.example.com/identity_credential"
            ]
          },
          "claims": [
            {
              "path": ["last_name"]
            },
            {
              "path": ["first_name"]
            },
            {
              "path": ["address", "street_address"]
            }
          ]
        }
      ]
    }
  },
  "signatures": [
    {
      "protected": {
        "x5c": ["mcnwmx...."], // access certificate based on EU trust list
        "typ": "JWT",
        "alg": "ES256",
        "attachments": [
          {
            "format": "registration_certificate",
            "data": "base64-encoded-registrationCertificate-jws"
          },
          {
            "format": "authorization_certificate",
            "data": {},
            "credential_ids": ["my_credential"]
          }
        ]
      },
     "signature": "dmfuwnbd..."
    },
    {
      "protected": {
        "x5c": ["cwknoihnkjnkjn"], // x5c from the LEI certificate
        "typ": "JWT",
        "alg": "ES256",
        "attachments": [
          {
            "format": "trust_list",
            "data": "http://exmaple.com/trust-list"
          },
          {
            "format": "ocsp",
            "data": "83efknKJsacklieqaf..."
          }
        ]
      },
      "signature": "mdbkhjq39n..."
    }
  ]
}

In case there is only one relying party involved (or just the need to pass one signature), the attachments is placed into the payload and the JWS is in its compact form (decoded for better representation):

{
  "x5c": ["cwknoihnkjnkjn"], // x5c from the LEI certificate
  "typ": "JWT",
  "alg": "ES256"
}.
{
  "response_type": "vp_token",
  "client_id": "x509_san_dns:client.example.org",
  "response_mode": "direct_post",
  "dcql_query": {
    "credentials": [
      {
        "id": "my_credential",
        "format": "vc+sd-jwt",
        "meta": {
          "vct_values": ["https://credentials.example.com/identity_credential"]
        },
        "claims": [
          {
            "path": ["last_name"]
          },
          {
            "path": ["first_name"]
          },
          {
            "path": ["address", "street_address"]
          }
        ]
      }
    ]
  },
  "attachments": [
    {
      "format": "registration_certificate",
      "data": "base64-encoded-registrationCertificate-jws"
    },
    {
      "format": "authorization_certificate",
      "data": {},
      "credential_ids": ["my_credential"]
    }
  ]
}.
signature

When going for a multi RP approach, there needs to be an identifier how the Wallet knows which signature entry belongs to which "eco system" without the need to decode all the entries first. so maybe an entry in the protected header to define the eco system.

So format and data would be a required field, while credential_ids is optional since not every entry has to be limited to one of the requested credentials (maybe it can even be removed since it's format specific and defined by the eco system).

[cre8]

After some feedback there could be multiple approaches where to pack the credential:

when it's in the json serialization, the attachments object can be placed in each protected header (supporting either the multi rp approach or giving the chance to sign the request with multiple certificates in case the trust eco system is not clear during the presentation request).

In case of the compact form (when there is just one RP singing the request), we place the attachments into the payload (same approach like client_id from the multi rp issue).

@awoie raised the question in the last meeting how to support a "proof of possession" e.g. when another x509 certificate is passed as attachment. This is out of scope of this feature, but up to the use case where the "format" is used. E.g. when a PSD2 certificate is used, the data field can be an object including the certificate and the signature over the nonce of the request (and maybe also a timestamp, etc) as a proof. But as said this is up to the ecosystem the RP (server) and the wallet (client) are included.

[Sakurann]

WG discussion

• suggestion: define attachments as a regular top-level parameter in the body of a request, and its behavior in multi-RP request is the same as client_id (in the header)
  • inside client_metadata vs top-level? -> top-level
  • either in the header for both single and multi-RP request or in the payload for both?