Introduction

Digital identity wallets must ascertain the identity of Verifiers and determine whether these Verifiers possess the necessary authorisation or obligation to request Verifiable Credentials (VCs) or claims. Examples illustrating this concept include:

1. Medical Card Access: Medical card information is restricted solely to accredited medical institutions and pharmacies.
2. Portable Document A1 Presentation: The portable document A1 is exclusively presented to accredited work inspectors.
3. Online Shopping: Verifiers are permitted to request payment and delivery information exclusively when engaging with online shops.
4. Adult Content and Alcohol Sales: Websites offering adult content or facilitating the sale of alcohol and similar products must request an over-18 credential, among other requirements.

This document introduces a Verifier Trust Model designed to manage Verifier rights and obligations efficiently. Additionally, it provides a straightforward and effective Verifier authentication and identification approach. This framework aims to foster transparency and security within the digital identity ecosystem, aligning with the principles of open public standards.

Confidentiality levels

The following confidentiality levels are introduced:

1. Public: This category encompasses information that is openly available and accessible to anyone without limitations or restrictions. VCs may contain personal information. In such cases, the processing of the information is subject to the GDPR. Examples include name, surname, address and date of birth.
2. Restricted: This category includes information that is subject to limitations or control and typically governed by specific rules, regulations or access permissions. Examples include accounting data, tax information, employment recommendations and HR records. Importantly, the holder of this information has the authority to override sharing restrictions.
3. Confidential: This classification pertains to information maintained as private and restricted solely to authorised individuals or designated groups. Examples include medical records, legal documents and other forms of highly confidential data. It is crucial to note that the sharing of confidential information cannot be overruled.

Confidential information can only be shared with a specific audience. VCs MUST contain a strict sharing policy, Verifiers MUST be identified, and Verifiers MUST present the requested Verifiable Attestations that grant them right to request a specific VC.

This classification framework provides informational clarity and flexibility, allowing each use case to establish its information sharing policies. Sharing restrictions can be defined at various levels, such as:

a) Organisation-Level Restrictions: Information can be shared with an entire organisation. For instance, employment recommendations may be shared with the HR department of a company.
b) Department-Level Restrictions: Information can be shared with specific organisational departments. For example, employment recommendations can be shared exclusively with the HR department of a particular organisation.

This framework offers a versatile foundation for defining and managing information access and sharing based on different contexts and organisations' unique needs and requirements.

VC Request and Presentation Policies

This section outlines a framework for expressing policies related to requesting and presenting VCs. Whenever Verifiers want to request restricted or confidential information, they MUST present one or more Verifier Authorisations to the wallet to express the right to request the information. VC Issuers can define requirements or policies for presenting the VCs. This way they can control and limit the sharing of restricted or confidential information.

The diagram below summarises a simple example where a Trust Framework:

• identifies Trusted Issuers for Student IDs
• identifies Trusted Issuers for Verifier Authorisations
• defines the Presentation Policies: a set of VCs the Verifier needs to present
• defines the Request Policies: which Verifiers may request specific claims or VC types

VC Presentation Policies

Presentation Policies must be defined in the termsOfUse property of a VC. This property allows issuers to specify rules and policies governing the presentation of VCs. The following basic VC Presentation Policy data model:

Property	Type	Value	Default Profile	Notes
type	string	REQUIRED. MUST be PresentationPolicy	PresentationPolicy
confidentialityLevel	string	REQUIRED. Recommended to be one of: · public · restricted · confidential	public	Use cases can introduce additional or different confidentiality levels.
requiredCredentials	array of JSON objects	OPTIONAL. booleanDefines a list of Verifiable Credentials the Verifier MUST present to be eligible to request the VC	N/A
requiredCredentials[].types	array of strings	REQUIRED. The requiredCredential must contain the following types	N/A
requiredCredentials[].limitRootTao	array of strings	CONDITIONAL. The requiredCredential must be issued by an issuer belonging to the trust chain of one of the Root TAOs. REQUIRED when confidentialityLevel is restricted or confidential.	N/A
requiredCredentials[].trustFramework	array of strings	CONDITIONAL. The requiredCredential must be issued under a specific trust framework.	N/A
pii	enum: none, indirect, sensitive	REQUIRED. Marks whether the Verifiable Credential contains personal information or not.	none

Use cases and Issuers can define Presentation Policies. The default profile MUST be assumed if a Presentation Policy is not defined in the VC.

Example Credential Presentation Policy

Example of Presentation Policy

{
  <>
  "termsOfUse": {
    "type": "PresentationPolicy",
    "confidentialityLevel": "confidential",
    "requiredCredentials": [
      {
        "types": ["VerifiableCredential", "VerifiableAttestation", "LegalEntityVerifiableID"],
        "trustFramework": "eIDAS",
      }, {
        "types": ["VerifiableCredential", "VerifiableAuthorisation", "VerifierAuthorisation"],
        "limitRootTao": ["did:ebsi:123"]
      }
    ],
    "pii": "none"
  }
}

In this example, the VC can be shared only if the Verifier

• presents two Verifiable Attestations that attest the following information:
  • Legal Entity Verifiable ID issued under eIDAS trust framework
  • Verifier Authorisation defining the VC or claims that can be requested, issued in Trust Model of did:ebsi:123.

The wallet MUST reject the presentation of the VC if any of the checks fail.

Request Policies

Verifiers must articulate their entitlements and obligations regarding the types of VCs or claims they can request. This section introduces a structured approach for expressing these authorisations using Request Policies issued as VCs.

Request Policies are expressed using input descriptors (DIF Presentation Exchange v2) and are issued as VCs.

A single VC can contain one or more input descriptors. Verifiers should tailor their input descriptors according to their Request Policies. Wallets MUST always verify whether the VCs they present meet the Request Policies and do not share more information than specified in the Request Policies. The process is as follows:

• Wallet receives Presentation Definition as part of the Verifier's VP Request
• Wallet receives one or more Verifier VCs shared by the Verifier
• Wallet prepares the VCs as requested in the VP request
• Wallet processes the Verifier's Request Policies and checks whether the Verifier is not over-asking
• If the Verifier is over-asking, the VP response MUST only contain information the Verifier is entitled to request

Note: The Verifier may ask for less information. In that case, the wallet only shares the requested information.

Property	Type	Value	Default Profile
permissions	array of objects	REQUIRED.
permissions[].type	string	REQUIRED. MUST be RequestPolicy	RequestPolicy
permissions[].input_descriptors	object or array of objects	REQUIRED. It MUST contain one or more input_descriptors the Verifier can use. The wallet MUST check the VCs to be presented against the input_descriptors in the Request Policy VC. If the Verifier is asking for more information, the holder MUST be notified, and if the VCs allow (non-confidential VCs), the holder can share the extra information.

Example Request Policy VC

The Verifier is requesting a full VC (Student ID) by type. Credential Subject would contain the following input descriptor:

Request Policy VC

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "id": "urn:uuid:003a1dd8-a5d2-42ef-8182-e921c0a9f2cd",
  "type": [
    "VerifiableCredential",
    "VerifiableAuthorisation",
    "VerifierAuthorisation"
  ],
  "issuer": "did:ebsi:ziDnioxYYLW1a3qUbqTFz4W",
  "validFrom": "2023-01-01T00:00:00Z",
  "validUntil": "2025-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:key:z2dmzD81cgPx8Vki7JbuuMmFYrWPgYoytykUZ3eyqht1j9KbnTvvSLAcNJvfNeLNuB9Y3Mbhus5btx3CBNknmhSStgGbqhMkqfWNSYZ5Vd1A8xQdD948jQSEjShYE1SFe1wZSgsw5S4v6sfHVV2p6waDwh9hCjdWdjFUo3nyU1rYLbuZxg",
    "permissions": [
      {
        "type": "RequestPolicy",
        "input_descriptors": [
          {
            "id": "Student ID",
            "name": "Authorisation to request Student ID",
            "purpose": "Identification",
            "format": { "jwt_vc": { "alg": ["ES256"] } },
            "constraints": {
              "fields": [
                {
                  "path": ["$.vc.type"],
                  "filter": {
                    "type": "array",
                    "contains": {
                      "type": "string",
                      "pattern": "StudentID"
                    }
                  }
                }
              ]
            }
          }
        ]
      }
    ]
  }
}