Support for embedded disclosure policies

[millenc]

The Integrity and Core Functionalities implementing act draft that is now open for public consultation requires on Article 10. Embedded disclosure that wallet instances (units) support the notion of embedded disclosure policies:

1. Wallet providers shall ensure that electronic attestations of attributes with common embedded disclosure policies set out in Annex II can be stored in the wallet units that they provide. Wallet instances shall be able to process and present such embedded disclosure policies in conjunction with data received from the requesting wallet relying party.

2. 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.

Annex II. to this document establishes the following possible policies:

1. No policy, indicating that wallet users may only disclose electronic attestations of attributes to authenticated relying parties.
2. Authorised relying parties only policy, indicating that wallet users may only disclose electronic attestations of attributes to authenticated relying parties which are explicitly listed in the disclosure policies.
3. Specific root of trust, indicating that wallet users may only disclose the specific electronic attestation of attributes to authenticated relying parties with authentication certificates derived from a specific (or list of specific) root certificate(s).

This requirement is also mandated on Article 3. General provisions on the Interfaces and protocols implementing act:

4. embedded disclosure policies have been processed within the wallet unit in accordance with Article 11 of Implementing Regulation 2024/XXX regards integrity and core functionalities, where applicable;

This requirement was already present on the Architecture and Reference Framework v1.4.0 (ARF) on section 6.6.3.3 Wallet Instance evaluates disclosure policy embedded in attestation, if present:

The PID Provider or Attestation Provider optionally embeds a disclosure policy in the PID or attestation. Such an embedded disclosure policy contains rules determining which (types of) Relying Party are allowed by the PID Provider or Attestation Provider to receive which attributes from the PID or attestation.

If a policy is present in the PID or attestation, the Wallet Instance evaluates the policy, together with data obtained from the Relying Party or the User, to determine whether the PID Provider or Attestation Provider allows this Relying Party to receive the requested attributes. [...]

The Wallet Instance presents the outcome of the disclosure policy evaluation to the User in the form of advice, when requesting User approval. For example, "The issuer of your PID does not want you to present to <Relying Party name>. Do you want to continue?" Note that the User can overrule the disclosure policy evaluation outcome.

and specified further on Annex II. High Level Requirements - Topic 43 - Embedded disclosure policy. Regarding issuance the following requirements are relevant:

EDP_01: A PID Provider or Attestation Provider SHALL be able to include an embedded disclosure policy in a PID or attestation, as defined in the applicable rulebook.

EDP_08: The Commission SHALL establish non-mandatory rulebooks, in agreement with the EDICG for electronic attestation of attributes for a common and interoperable set of rules for including an embedded disclosure policy in an attestation, protocols between an EUDI Wallet Instance and a Relying Party and the presentation of the response from a Relying Party or the requesting user of the EUDI Wallet by a Wallet Instance to a Wallet User.

As far as implementing this requirement on credential issuances powered by OID4VCI, we can consider several options:

1. Include the disclosure policy as additional claim/s on the credential itself.
2. Add a new parameter (e.g. disclosure_policies) to the Credential Response (POST /credential) indicating the policy for each issued credential on credentials
3. Add a new parameter (e.g. disclosure_policy) to the Credential Issuer Metadata for the corresponding credential type under credential_configurations_supported

As far as I understand it, the requirements on the ARF point to option 1. as the preferred way to implement this, given the references on EDP_01 and EDP_08 to include the policy on the PID or attestation themselves according to the corresponding rulebook (which mainly consists of a schema of claims for said credentials). If this is the case, then the OID4VCI protocol would remain unchanged and it would be the responsibility of rulebook and data format spec owners to define profiles and schemas to support this requirement in an interopable fashion.

Option 1. raises some concerns though:

• Current PID/mDL rulebooks (Annex III. to the ARF) don't include any reference to disclosure policies
• The Person identification data and electronic attestations of attributes implementing act on its Annex specifies the data and optional attributes on PIDs but does not include support for embedded disclosure policies either
• If left to the data format (more like credential metadata rather than claims), specs such as SD-JWT-VC or ISO-mDL should add support for this in the form of profiles or custom parameters/claims. This should be done for all data formats to ensure interoperability
• Policy changes would require re-issuance of existing credentials

To address these concerns, options 2. or 3. (potentially others as well?) can be considered. These options require changes to the OID4VCI spec. The main advantage of these options over 1. is that the embedded disclosure policy can be communicated in a credential-format-agnostic way, hence eliminating the need for rulebooks or credential format profiles. In the case of 3., the issuer can also change the policy at a later time without requiring re-issuing credentials. The main drawback on this last option is the lack of version history, although the same is true for the any other metadata parameter (such as the display information).

Any thoughts on this are welcome.

[tlodderstedt]

I expect the credential to contain the issuer policy and the issuer decides what policy to add to which credential.

I also agree with your observation there is no solution yet. That needs a solution must be developed for the respective credential formats.

I don't see a need to add anything to the issuance protocol.

[cre8]

Hi @millenc ,

I presented the approach in our OpenOnlineConsultation, you can find the slides and recording here

In the session I presented a fourth option, where you are defining a policy based on DCQL instead of a static list or root of trust.

While the Implementing Act is talking about embedded, I specified two approached:

credential metadata

In case of sd-jwt-vc, you can link the policy in the metadata like:

{
  "vct":"https://example.com/education_credential",
  "name":"Education Credential - Preliminary Version",
  "description":"This is our development version of the education credential. Don't panic.",
  "extends":"https://galaxy.example.com/galactic-education-credential-0.9",
  "extends#integrity":"sha256-9cLlJNXN-TsMk-PmKjZ5t0WRL5ca_xGgX3c1VLmXfh-WRL5",
  "schema_uri":"https://exampleuniversity.com/public/credential-schema-0.9",
  "schema_uri#integrity":"sha256-o984vn819a48ui1llkwPmKjZ5t0WRL5ca_xGgX3c1VLmXfh",
  "authz": "http://example.com/policy/education_credential",
  "authz#integrity": "sha256-o984vn819a48ui1llkwPmKjZ5t0WRL5ca_xGgX3c1VLmXfh"
}

The downside of this approach is that not all credentials have such a metadata option. Alternatively you can also add them to the openid4vci issuer metadata like:

{
  "credential_configurations_supported": {
    "SD_JWT_VC_example_in_OpenID4VCI": {
      "format": "dc+sd-jwt",
      "scope": "SD_JWT_VC_example_in_OpenID4VCI",
      "cryptographic_binding_methods_supported": ["jwk"],
      "credential_signing_alg_values_supported": ["ES256"],
      "vct": "SD_JWT_VC_example_in_OpenID4VCI",
      "authz": {}, //policy is embedded or linked here
  }
}

The advantage of the linking, also without the integrity check, is that the issuer is able to update the policy, without the need to revoke all credentials that have an outdated embedded one (because you needed to remove one entry from the allow list).

For discovery (has nothing to do with eIDAS compliance), the reference in the issuer metadata will help Relying Parties to see what are the requirements to request successfully this type of credential from a wallet, when it got issued by this provider.

[millenc]

I expect the credential to contain the issuer policy and the issuer decides what policy to add to which credential.

I also agree with your observation there is no solution yet. That needs a solution must be developed for the respective credential formats.

I don't see a need to add anything to the issuance protocol.

@tlodderstedt That was my understanding as well. However, since writing this issue the EUDIW ARF has published several new versions (latest is v1.9.0 at the time of writing this comment) and worked on Topic D - Embedded Disclosure Policies (discussion issue). New HLRs related to this topic were introduced to the ARF on v1.8.0.

The discussion topic text and the new HLRs seem to favor option 3. on the OP for distributing EDPs:

3. Add a new parameter (e.g. disclosure_policy) to the Credential Issuer Metadata for the corresponding credential type under credential_configurations_supported

Specifically, from the discussion topic document (section 3.1):

(a) Embedded disclosure policies are provided in Provider metadata (e.g., by extending the "credentials_configurations_supported" field of the "credential issuer metadata" specified in section 11.2 of [OID4VCI]). This option does not require modifications to the attestation format.

Option (a) is the preferred distribution method. It is reminded that according to requirement [ISS_32a] "An Attestation Provider SHALL sign its metadata"

The relevant HLRs on the ARF are:

EDP_09: An Attestation Provider SHALL include an embedded disclosure policy (if any) by value in the Issuer metadata related to the attestation, in compliance with the [OpenID4VCI] issuance protocol or an extension thereof specified in the technical specification mentioned in EDP_08.

There's also a new HLR addressing my original comment:

In the case of 3., the issuer can also change the policy at a later time without requiring re-issuing credentials. The main drawback on this last option is the lack of version history, although the same is true for the any other metadata parameter (such as the display information).

that explicitly requires the issuer to revoke all credentials associated with a specific disclosure policy if that policy is changed at a later time:

EDP_11: An Attestation Provider SHALL revoke an attestation if a corresponding embedded disclosure policy is added, changed, or deleted.

This requirement introduces some complexity on the issuer's side, that needs to track which issued credentials are associated with each disclosure policy in order to handle revocations.

@cre8 Thanks for the references.

In the session I presented a fourth option, where you are defining a policy based on DCQL instead of a static list or root of trust.

This is very interesting. I agree that the proposed approach of using simple allowlists or roots of trusts is somewhat limited. However, that's the approach that is being favored right now, as it seems:

This is a complex and time-consuming process that would hinder the definition, standardization, and eventual deployment of such a policy definition language. Mandating support for such a language could create barriers to the development and adoption of Wallet Solutions. Therefore, this discussion paper does not propose any requirement for such a language.

The advantage of the linking, also without the integrity check, is that the issuer is able to update the policy, without the need to revoke all credentials that have an outdated embedded one (because you needed to remove one entry from the allow list).

See my previous comment on the requirement by the ARF to revoke credentials if their EDP changes. It seems the favored approach is the second option of your comment (embedding the policy on the issuer's metadata).