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:
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.
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:
No policy, indicating that wallet users may only disclose electronic attestations of attributes to authenticated relying parties.
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.
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:
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;
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 . Do you want to continue?" Note that the User can overrule the disclosure policy evaluation outcome.
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:
Include the disclosure policy as additional claim/s on the credential itself.
Add a new parameter (e.g. disclosure_policies) to the Credential Response (POST /credential) indicating the policy for each issued credential on credentials
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
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).
The Integrity and Core Functionalities implementing act draft that is now open for public consultation requires on
Article 10. Embedded disclosurethat wallet instances (units) support the notion of embedded disclosure policies:Annex II. to this document establishes the following possible policies:
No policy, indicating that wallet users may only disclose electronic attestations of attributes to authenticated relying parties.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.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 provisionson the Interfaces and protocols implementing act: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:
and specified further on Annex II. High Level Requirements - Topic 43 - Embedded disclosure policy. Regarding issuance the following requirements are relevant:
As far as implementing this requirement on credential issuances powered by OID4VCI, we can consider several options:
disclosure_policies) to the Credential Response (POST /credential) indicating the policy for each issued credential oncredentialsdisclosure_policy) to the Credential Issuer Metadata for the corresponding credential type undercredential_configurations_supportedAs 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_01andEDP_08to 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:
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.