Introduction

Digital identity wallets must be able to ascertain the identity of Verifiers and determine whether these Verifiers possess the necessary authorisation or obligation to request Verifiable Credentials or claims. Below, we provide examples to illustrate this concept:

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: For websites offering adult content or facilitating the sale of alcohol and similar products, they 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

We are introducing a the following confidentiality levels:

1. Public: This category encompasses information that is openly available and accessible to anyone without limitations or restrictions. Verifiable Credentials may contain personal information. In this case the processing of the information is subject to the GDPR. Examples include name, surname, address, and date of birth.
2. Restricted: Here, information is subject to limitations or control, 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 of such information include medical records, legal documents, and other forms of highly confidential data. It is crucial to note that sharing of confidential information cannot be overruled.

Confidential information can only be shared with very a specific audience. Verifiable Credentials MUST contain a strict sharing policy, verifiers MUST be identified, and verifiers MUST present the requested Verifiable Attestations that give them right to ask for a specific Verifiable Credential.

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. For example:

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

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 Verifiable Credentials. 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. Verifiable Credential issuers can define requirements or policies for presenting the Verifiable Credentials. This way they can control and limit the sharing of restricted/confidential information.

The diagram below summarises a simple example where a Trust Framework

• identifies Trusted Issuer for Student ID
• identifies Trusted Issuers for Verifier Authorisation
• defines the Presentation Policies: a set of VCs 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 Verifiable Credentials. We define 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 issuer can define Presentation Policies. The default profile MUST be assumed if PresentationPolicy 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 Verifiable Credential if any of the checks fail.

Request Policies

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

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

A single verifiable credential can contain one or more input descriptors. Verifiers should tailor their input descriptors according to their Request Policies. Wallets MUST always verify whether the Verifiable Credentials they're about to present, meet the Request Policies and don't share more information than specified in the Request Policies. The process is following

• 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",
            "constraints": {
              "fields": [
                {
                  "path": ["$.type"],
                  "filter": {
                    "type": "array",
                    "contains": {
                      "type": "string",
                      "pattern": "StudentID"
                    }
                  }
                }
              ]
            }
          }
        ]
      }
    ]
  }
}