Disclosure policy of verifier authorization

In some scenarios we want to limit which verifiers are able to consume a specific credential, e.g. an issued employee card should only be presented to listed entities, not anyone else.

In the eIDAS implementing acts this action is called embedded disclosure:

Embedded disclosure

1. Wallet providers shall ensure that electronic attestations of attributes with common embedded disclosure policies set out in Annex III can be processed by the wallet units that they provide.
2. Wallet instances shall be able to process and present such embedded disclosure policies referred to in paragraph 1 in conjunction with data received from the requesting wallet-relying party.
3. Wallet instances shall verify whether the wallet-relying party complies with the requirements of the embedded disclosure policy and inform the wallet user of the result.

In the German funke innovation competition we tested four approaches, the handling is described here.

Reason to not implement on credential level

one approach could be to include it into metadata which would be possible for sd jwt vc. But this approach is credential format independent, so it would be better to include it into the issuance protocol.

To realize this, multiple questions need to be solved:

placing of the policy

• root level, linked in the credential_configurations_supported:
  • on root level there is a list of policies, each credential configuration can then link to it.
  • Good to reuse policies for multiple definitions
• embedded into a credential configuration

referenced or embedded

The content could be referenced by value or embedded. In general most profiles require that issuer metadata is downloaded during the issuance process instead of requested in an internal to check for updates. I would prefer this approach to avoid phone home problems, fetching has to be defined by a profile like HAIP or so. Down side of embedded is a bigger size of the issuer metadata.

approaches

It should be possible for other eco system to define own approaches to manage verifier authorization, this spec may only define some in the beginning.

granular approach

to limit on claim sets, the usage of DCQL logic can be used. It has to be discussed if this is fine for the working group or if this will bind to too strong to OID4VP. One approach could also be that the policy is always bound to a presentation approach and not just the authorization logic (like allow list + DCQL + OID4VP)

Personal interest is in the attestation based policy approach like this:

{
  "policy": "attestationBased",
  "options": [
    {
      "claims": [{ "path": ["last_name"] }],
      "credentials": [
        {
          "id": "membership",
          "meta": { "vct_values": ["https://example.com/membership"] },
          "format": "sd-jwt-dc",
          "trusted_authorities": {
            "type": "aki",
            "values": ["s9tIpPmhxdiuNkHMEWNpYim8S8Y"]
          }
        }
      ]
    }
  ],
  "url": "https://example.com/disclosure-policy"
}

since it does not require any updates by the wallet to get the latest list of authorized verifiers since it already has the logic to know which verifier is authorized (of course an update is needed when other credentials are needed).

Idea was pitched at last IIW to some DCP members, but I would like to get more feedback. Also happy to provide the PR in case the group sees a value in this feature. From the time perspective my goal would be to have it final in the next three months.

Start with the linked eIDAS disclosure-policy appendix and the issue's questions about policy placement, embedding, verifier authorization, and DCQL. Compare the proposed attestation-based example with the issuance protocol and credential_configurations_supported; done means the working group has agreed on a concrete, format-independent policy design and its specification scope.