OID4VC with Wallet-Relying Party Attestations

When dealing with Wallet-Relying Party Authentication or Disclosure Policies, the issued certificates like access and registration certificates and authorization attestations should be included in the request from the Wallet-Relying Party. When they need to be fetched by the Wallet from the RP registrar, the Registrar would be able to monitor which wallet is interacting with which Relying Party. Instead the Wallet will only request the status information from the registrar by fetching the CRL or Status List.

Issuance

OID4VCI flow with certificates

Before issuing a credential into the Wallet, the Issuer has to authenticate against the EUDI Wallet before it receives the credential or presents any information during the authorization phase. To do this, the issuer has to sign its published Credential Issuer Metadata and also include the registration certificate.

Step by Step:

1. Wallet fetches the trust anchor from the EU
   • List of List as the Root of Trust
   • This step must not be done for each request, but the list should be up to date
2. Wallet downloads and stores the list of RP Registrars
3. Wallet fetches the Credential Issuer Metadata from the Issuer
4. Issuer response with the Credential Issuer Metadata
   • If no signed metadata is provided, the process stops
   • The Access Certificate is included in the header of the JSON Web Signature
5. Wallet is validating the RP's identity
   • Wallet validates the chain of trust of the request form the Access Certificate to the list of list it fetched before
   • In case of a the chain of trust is not valid, the process stops
6. Wallet fetches the CRL from the RP Registrar
   • In case the trust chain is revoked, the process stops
7. RP Registrar response with the CRL
   • If no CRL is provided or one certificate is revoked, the process stops

Presentation

OID4VP flow with certificates

The following diagram outlines the process of a presentation request where the Relying-Party with the required certificates.

Step by Step:

1. Wallet fetches the trust anchor from the EU
   • List of List as the Root of Trust
   • This step must not be done for each request, but the list should be up to date
2. RP creates the presentation request
   • Uses the key from the access certificate to sign it
   • Includes all Registration Certificates that cover the values that should be requested
   • Includes the Authorization Attestation that are required for the request.
3. RP sends presentation request to Wallet
4. Wallet is validating the RP's identity
   • Wallet validates the chain of trust of the request form the Access Certificate to the list of list it fetched before
   • In case of a the chain of trust is not valid, the process stops
5. Wallet validates requested data against intended use
   • Validates the chain of trust of the passed Registration Certificate
   • Validates if the requested data is equal or a subset of the Registration Certificates
   • If one of the validations fails, the process is aborted. The user is able to report the incident, where it sends all the information to service to validate it. The report process is out of scope of this spec.
6. Optional: Wallet fetches the issuer disclosure policy from the issuer metadata
   • In case none is defined, step 7 is skipped
7. Optional: Wallet validates the policy against the the passed Authorization Attestations
   • Validates chain of trust
   • Validates if all requested credentials are covered with the policy
   • In case one of the validation is invalid, show a warning to the user, but do not abort the flow (RP could still have a valid reason to fetch it).
8. Wallet requests a user interaction
   • User gets the information who is requesting data with which purpose
   • In case a warning from step 7 was generated, show it here
9. User approves the request
10. Wallet creates a presentation response and sends it to the Relying Party

The flow continues by the verification of the response by the RP.

Presentation request

To pass a Registration Certificate or Authorization Attestation to the Relying Party, they can be included in the authorization request, as defined in the OID4VP specification

{
  "x5c": [], // chain of trust, starts with access 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":"dc+sd-jwt",
        "meta":{
          "vct_values":[
            "https://credentials.example.com/identity_credential"
          ]
        },
        "claims":[
          {
            "path":[
              "last_name"
            ]
          },
          {
            "path":[
              "first_name"
            ]
          },
          {
            "path":[
              "address",
              "street_address"
            ]
          }
        ]
      }
    ]
  },
  "verifier_attestations":[
    {
      "format": "jwt",
      "data": "eyJhbGc...6yJV_adQssw5c"
    },
    {
      "format": "dc+sd-jwt",
      "data": "eyJ0eXAiOiJ...zLTQ1LTY3ODkiXQ~",
      "credential_ids": ["my_credential"]
    }
  ]
}

Verifier Attestations

When the Wallet receives the authorization request with the list of attestations, the Wallet needs to decode all of them based on the format to check the type of the attestation.

Registration Certificate: To get the Registration Certificate, the attachment must have the format jwt. The data field has to be decoded and the typ field must be equal to rc-rp+jwt.

Authorization Attestation: Each credential, that is not a Registration Certificate, is treated as an Authorization Attestation. For possible formats, see the examples section like for SD-JWT-VC.

Open Topics

Support of Proximity Flow

TBD.