Accountable Digital Identity Association (ADIA) Specification

Editor’s Draft,

Issue Tracking:
GitHub
Editors:

Copyright © 2022 ADI Association. All Rights Reserved.

Abstract

The Accountable Digital Identity Association (ADIA) Specification establishes the foundational technology components to establish a Trustable Identity Framework by providing a unique Digital Address for Human Identities to empower them to manage their Identity information and reinforce Trust and Accountability in the Digital World.

1. Accountable Digital Identity Architecture

This section is not normative.

1.1. Introduction

Establishing an effective model for digital identity is a priority that spans industries. The traditional identity model for the digital world has been an account with a password. Service Providers give each of their customers an account and assume that those accounts can be secured. However, accounts are breached, and data are compromised. Service Providers do not often even know if the person who created the account was legitimate.

In the physical world, individuals can prove who they are by presenting formal documents like a driver’s license, passport, or birth certificate. In the digital world, individuals cannot definitively prove who they are, and the malicious can easily masquerade as someone they are not.

This gap between physical and digital identity has led to an exponential increase in online fraud as more interactions and financial transactions have gone digital. It has also led to a rapid rise in misinformation and disinformation propagating through online social media.

ADI Association agrees with industry experts, standards bodies, governments, and global companies that addressing these issues is a priority. ADI Association believes:

Using these insights, ADI Association designed an architecture for Accountable Digital Identity (ADI). Its goal is to define a global digital identity framework that establishes trust and accountability across all participants. This framework must be open, interoperable, trustable across borders, and equitable across participants.

In the physical world, identities are created at birth by a trusted group of people. Parents choose names; hospitals record birth events; and governments create birth records, which are then used by individuals to register at schools, employers, banks, medical facilities, and so on. Everything an individual does in life is tied to that identity, and that identity becomes the accountable party. ADI Association has defined a similar concept for the digital world, called the “Digital Address.”

A Digital Address is created when a User is onboarded by a trusted Issuer who has an existing, vetted relationship with that User. Educational institutions, employers, financial institutions, medical facilities, and government entities like the DMV and Passport Office can play this role. A unique cryptographic representation of the User is created with attributes that are unique to the User. The User binds to this representation using FIDO. The representation is then given a user-friendly name, called the Digital Address. The Digital Address is the human-readable representation of the unique cryptographic key created for the User by a trusted identity source.

Once the Digital Address is created and bound with FIDO credentials, the User can request their personal data to be linked to that Digital Address. The personal data stays at the original source in a W3C Verifiable Credential format. Only metadata, using decentralized identifiers, is stored at the ADI Interchange, which is the service point that connects Users, Issuers, and Service Providers. This allows Users to share their personal data with Service Providers of their choice, disclosing only the information relevant to the requestor. Privacy is preserved because data is not shared without the consent of the User.

Service Providers can trust the system because data verification comes directly from the Issuers. The Interchange keeps track of all interactions using one-time identifiers attached to the Digital Address. If there is ever a need to get details of any User for any interaction, the Interchange can provide the Service Provider with the issuing information for that Digital Address. This brings accountability into the system, which can then be leveraged under appropriate legal and governance frameworks to provide accountability across borders.

An ADI Interchange onboards Users, Issuers, and Service Providers in a trusted manner and enables them to interact with each other. They can verify identity to mitigate fraud, and they can preserve privacy and consent to improve regulatory compliance. Interchanges in different regions of the world work independently of each other but communicate and interoperate as described in this specification.

The principles underlying the design of the ADI architecture and the definition of the specification are:

  1. Make creating and using a Digital Address simple for Users

  2. Make deployment simple for Issuers and Service Providers.

  3. Integrate with existing identity infrastructure and data stores.

  4. Support existing applications and infrastructure without requiring changes.

  5. Provide interoperability across different ADI Interchanges.

  6. Support cross-border and cross-region identity, including issuance and verification of data credentials.

  7. Encourage cross-network value settlements.

  8. Support all Users, including those without a smart device.

The ADIA specification comprises of:

1.2. Ecosystem Overview

Accountable Digital Identity Architecture (ADIA) is a decentralized network of networks integrating Regional Directories, Interchanges, Issuers, Service Providers and Users with unique Trust Anchors. All entities within the architecture are represented by DIDs. Each DID is resolvable to a DID Document which contains cryptographic keys and service endpoints as specified in the DID Core Specification.

The focus of the ecosystem is to:

ADIA Overview

The ecosystem consists of entities that are involved in the trust framework. They are:

These entities and their role in the ADIA ecosystem are described in § 1.5 Roles in ADIA.

1.3. Trust Anchor

Trust Anchor (TA) is a unique identifier for a given entity in the ADIA ecosystem and is registered in an ADIA Directory. A Trust Anchor uniquely maps an entity’s Digital Address and a DAS-assigned DID.

The ADIA Directories (AGD and ARDs), for regulatory purposes and user privacy, do not store any personal information about a user or an entity. Directories support a user’s right to be forgotten that is defined in many jurisdictions.

Directories MAY use a Universally Unique Identifier (UUID), a Globally Unique Identifier (GUID) as specified by [RFC4122] or an opaque 128-character random character string to represent the Trust Anchor.

1.4. Digital Address

DIDs are the foundational identifiers of the system but are not participant friendly. The Digital Address is a special ADIA identifier issued to an individual by a certified Digital Address Issuer after Know Your Customer (KYC) processes have been followed. Digital Addresses are designed to be human friendly and facilitate interaction with entities. When they present their Digital Address to a participating service, the service can contact the directory and receive a DID that represents the participant. Further communication and cryptographic trust are then founded on the provided DID. Digital Addresses contain a DAS indicator that can be used to identify which DAS is the Home DAS of the Digital Address.

The creation of a Digital Address is a crucial step in ensuring there is both trust and accountability within the ADIA ecosystem. Digital Address Issuers could be financial service providers, government agencies, education providers and enterprises; organizations that are central to the trust economy. To prevent the Digital Address from being misused as a correlation handle, Digital Addresses must not be retained by participating Service Providers after resolution. Their role is specifically limited to facilitating the participant-onboarding processes.

1.4.1. Uniqueness

Entities in ADIA shall not have more than one Digital Address. To ensure this uniqueness, the identity-related traits for a user are verified and hashed by an Issuer Agent. This specification defines the attributes for all entities to create a HIDA, a cryptographic hash computed over the identifying attributes, such as:

The HIDA is used to query the Directory to determine uniqueness of the User or Entity based on the identity attributes provided. The process of binding the Digital Address with the Trust Anchor notifying the user is described in § 2.1.5.1 Issuer Initiated New User Enrollment

Please see § 4.3 HIDA Computation details for users and other Entities.

1.4.2. Format

The Digital Address is a user friendly mnemonic that maps to a technical identifier, the DID for the user or Entity. Participants may change their Digital Address at a later point in time.

The format is specified as follows:

@HomeDASIdentifier

Please see § 4.2 Digital Address Format for the format for Users and Entities.

1.5. Roles in ADIA

1.5.1. ADIA Global Directory

The ADIA Global Directory (AGD) serves as a Root of Trust for all non-User entities in the ecosystem. The Directory ensures interoperability between multiple Regional Directories and Interchanges. Uniqueness of the entities is defined by the relationship of identifiers - the Entity’s Digital Address, the DID and the Trust Anchors and binding them to organizational entities at a global level.

1.5.1.1. Directory Scope

The [ADIA-Specification-Governance], defines onboarding policies and procedures for organizational entities and establishes the relationships between the Digital Address, the DID and Trust Anchor. The entities governed by the ADIA Global Directory are:

The ADIA Global Directory may provide Discovery and Routing services between one or more Regional Directories (ARD) to facilitate identity verifications across one or more geographical regions.

1.5.1.2. Uniqueness properties

ADIA Global Directory ensures uniqueness of the listed organizational entities. This is done by ensuring a unique set of attributes for each organization.

Please see § 4.3.2 HIDA for Organizational Entities for uniqueness properties for Issuers, Service Providers, DAS and Regional Directories (ARDs).

1.5.1.3. Directory Querying

A qualified party may query the directory by providing attributes or a digital address. The directory will either return a ‘None Found’ response, or a DID of the entity identified. The ADIA Global Directory has several components that enable saving Trust Anchors and relationships:

1.5.1.4. Roles

The types of actors that interact with ADIA are described below:

1.5.2. ADIA Regional Directory

The ADIA Regional Directory (ARD) is a directory that serves to identify participants within an ecosystem. This can make it easier for Users without a digital device or knowledge of how to use one. Users can be looked up by attributes or a digital address, both of which are discussed in this spec.

1.5.2.1. Directory Scope

Each directory serves a particular scope. Scopes can be geopolitical, like a country, or organizational, such as a multi-national medical organization or a university. Each directory serves to uniquely identify each participant via digital address or a collection of attributes.

An ADIA Regional Directory shall:

Directory scopes can and will overlap. A university may run a directory for students and faculty in a country where a directory is run for the country. People may be listed in multiple directories without conflict. Initial directories will be run by ADIA to seed the ecosystem. Other entities may operate directories in conformance with the [ADIA-Specification-Governance] and APIs.

1.5.2.2. Attribute selection and management

Each directory has a set of attributes used to list users in the directory. These attributes are received via credentials from issuers authorized by the appropriate [ADIA-Specification-Governance]. When necessary for uniqueness (described in the next section), the directory may request additional attributes from a user, also supplied via credentials.

Directories may use any datastore sufficient to the requirements of storing attributes. Datastores must be able to remove listed records at the request of the user.

1.5.2.3. Uniqueness properties

ADIA Directories ensure uniqueness of the listed users. This is done by ensuring a unique set of attributes for each user. If a new user matches an existing user, additional attributes must be requested for use in distinguishing between the matching users. Each directory MUST have a process to follow when users cannot be uniquely identified either during addition of a user to the directory or during lookup of a user within the directory.

Please see § 4.3.1 HIDA for Users for uniqueness properties for Users in the ADIA Regional Directories (ARDs).

1.5.2.4. Directory Querying

A qualified party may query the directory by providing attributes or a digital address. The directory will either return a ‘None Found’ response, or a DID of the user identified. The DID provided is created by the user’s agent, and provided to the directory for the purpose of returning to the party querying the directory. The user’s agent is notified of which party identified them in the directory.

The protocols for querying users are summarized and linked below.

1.5.3. Interchange

The Interchange is composed of one or more the services that provide User Access services such as, Digital Address and Authentication for users, Agency services such as Issuer and Service Provider Agents and optional value-added services such as Identity Escrow, Credential Brokerage and Payment Brokerage services.

1.5.3.1. DAS

Digital Address Service (DAS) plays a major role of enabling the identity and business transactions between issuers, service providers and users. The DAS uses a combination of on-Ledger and off-Ledger services to facilitate the capabilities of verifying credentials for relying parties.

The DAS may host a set of user-focused Cloud Agent and secure communication agents with other agents in the ecosytem. When any interaction with a participant happens, it happens through their Agent via services. Each entity’s Agent holds cryptographic keys and digital credentials on behalf of the participant. The agent also manages the participant’s connections with services in the ecosystem. It maintains the participant’s directory listings and requests for unique DIDs when a new connection is made. The Agent is configured with and uses machine-readable governance framework documents as policy for automatically accepting or rejecting credential interactions. When necessary, the agent will communicate with the participant through a secure channel and obtain consent. Participants authenticate to the Agent via FIDO when consent is required. All interactions through the agent are logged and available for inspection by the entity.

1.5.3.1.1. Components

The core components of a DAS are:

1.5.3.1.2. Roles

The types of actors that interact with the DAS are described below:

1.5.3.2. Credential Broker (Future)

The process of receiving credential presentations can be complicated. Verifiers and participants may enlist the use of a Credential Broker. The broker can serve several functions in the process of aiding a credential presentation. The credential may be translated between formats, verifying one format and creating another that is readable by the verifier.

The broker can do the legwork of applying governance frameworks and checking the credential issuer for validity. This is particularly helpful when interacting with an interchange provider not previously known to the verifier. The broker must involve the participant’s agent and, in the process, obtain consent to share the user’s credential. During the exchange of the credential, the broker may also facilitate payment to the parties involved in the credential’s issuance and flow.

1.5.3.3. Identity Escrow (Future)

Privacy preserving accountability is provided by Identity Escrow Services. Identity data is presented to the Identity Escrow Service in a credential from an approved issuer. The Escrow Service stores the data and issues an escrow credential to the participant. Each escrow credential obtained by the participant contains a unique id.

Upon connecting to a new service, the participant presents the escrow credential. The service validates the credential, and then retains the unique id. Should the participant violate the terms of service or otherwise require accountability for their actions, the service will present the request and evidence to the Escrow Service. The escrow service will evaluate the request and evidence against their policies. If policy indicates, the escrow service will notify the participant of the disclosure, disclose the identity data from escrow, and log the evidence and disclosure for independent audit. Disclosure logs are retained for a period set by policy.

Both the service and the participant must agree on the terms and policy of the Identity Escrow Service. The use, policy, and terms of Identity Escrow use should be contained within applicable governance frameworks. The right to be forgotten may be delayed for a period of time to allow adequate time for violation disclosure requests to be processed and resolved.

1.5.3.4. Payment Broker (Future)

Financial transactions are another area that can benefit from the involvement of a broker. The Payment Broker may perform currency conversions to the benefit of both parties. The broker will also communicate with all parties in the payment flow. When required by law, the broker can log the transaction sufficiently to satisfy regulation such as Anti-Money Laundering (AML) laws. Payment flows can be used for credentials but may also be used for general purpose payment. In the future, payment can also involve verifying goods delivery prior to releasing payment.

1.5.4. Issuer

In the ADIA system trust between entities is brokered by the DAS. Issuers of a Verifiable Credential are separated from the Service Providers (i.e. verifiers of Verifiable Credential). Issuers are also custodians of a Verifiable Credential owned by the User it is issued to. ADIA supports multiple Issuers per User. Issuers use an Issuer Agent to connect to the DAS.

1.5.4.1. Components

The core components of an Issuer are:

1.5.4.2. Roles

1.5.5. Service Provider

Service Providers (SPs) are relying parties in the ecosystem. Credential verification is requested from a User to identify the user reliably before providing services. In the Decentralized Identity community this role is typically called Verifier.

The proof requests are defined by Service Providers from one or more Credential Schema published by Issuers in the ADIA ecosystem. The verification rulesets may be defined based on a combination of criteria:

Service Providers may take a risk-based approach based on their enterprise needs and risk management policies before accepting the Verifiable Presentations made by a User.

1.5.5.1. Components

The core components of a Service Provider are:

1.5.5.2. Roles

1.5.6. User

A User is a holder of a unique Digital Address and receives it from an Issuer after the respective ID Proofing process is completed. The User can then use their Digital Address for various purposes; for example, receiving Verifiable Credentials such as an Identity Credential, or credentials that prove Educational qualifications, Health records, Employment proofs, etc.

1.5.6.1. Scope

The User is cryptographically represented by the Cloud Agent. The Cloud Agent is a cloud accessible entity that acts on behalf of the user. More specifically this entity reliably maintains the cryptographic material (e.g. DAS_USER_ID_SK) that is required for the interaction with the other entities. Users may select a Cloud Agent of their choice. The User uses its DAA to securely communicate with the (remote) Cloud Agent.

This Cloud Agent role has some similarity to the eIDAS Trust Service Providers, which may also maintain cryptographic material - in this case for creating legally binding electronic signatures - on behalf of the User.

1.5.7. Digital Address Application (DAA)

For Users to be part of the ADIA ecosystem, they must be in control of a Digital Address. The Digital Address may be acquired via many forms - often via a QR code over some channel such as an Authenticator App, Email, SmartCard or directly from an Issuer.

The Digital Address Application (DAA) is an "Authenticator App" that lets users scan a Digital Address, bind the Digital Address to the DAS and enable the receipt of and provide consent for verification requests.

1.5.7.1. Components

The core components of a Digital Address Application are:

1.5.7.2. Roles

The types of actors that interact with the Mobile App are described below:

1.6. Assurance Level

ADIA provides a Governance Framework to ensure that Trusted entities are deemed Issuers in the overall ecosystem. This combines a set of policies and procedures to verify that Issuers are verified by a Registration Authority and entity issuing Verifiable Credentials is an organization with Good standing Rating, Financial Standing, Risk of Failure, Insurance and maturity of the processes in collecting, verifying, storage and access to Credentials for all its constituents is in accordance with the ADIA ecosystem standards and local jurisdiction.

1.6.1. Applicability

There are types of Assurance Levels that may be addressed in the future version of the specification:

1.6.2. User Assurance Level

This specification deems the need for such levels but defers the definition of these levels to a future release. The current version of the specification aligns with the NIST 800-63A Digital Identity Guidelines to determine the Assurance of the User acquiring the Digital Address. There primarily apply to the identity proofing performed by the Issuers or the Users themselves at the time of issuing and/or importing the Digital Address.These levels are:

1.6.3. Usage

Service Providers may create complex criteria for requesting proofs from users, including the Assurance Level of any entity or the type of the VC to ensure the identity of the User before rendering any services.

1.6.4. Transitions

Users may acquire a Digital Address with a lower level of assurance, e.g. start with lowest level identity assertion to join the ecosystem, but transition to a higher level of U-AL by either remotely proving their identity or approaching an Issuer in the ADIA ecosystem and presenting valid identity credentials.

1.7. Key Protection Level

There are multiple different cryptographic keys involved in the ADIA system. The degree to which entities want to trust the claims typically is impacted by the protection of those keys. In other words, if cryptographic keys get extracted or used without proper permissions, malicious claims could be generated.

The ADIA system provides transparency about the key protection levels.

1.7.1. Key Protection Against Extraction

The following Key Extraction Protection levels are defined:

Software
For an attacker to extract the private cryptographic key material in the clear, it is sufficient to break the Rich Operating System of the Key Holder.
Trusted Execution Environment
For an attacker to extract the private cryptographic key material in the clear, it is sufficient to break the Trusted Execution Environment of the Key Holder.
Secure Element
For an attacker to extract the private cryptographic key material in the clear, it is sufficient to break the Secure Element of the Key Holder.

Additionally, the ADIA system tracks the entity that asserted the Key Extraction Protection level as follows:

Self-asserted
The entity running the Key Holder systems self asserted the Key Extraction Protection level.
Third-party asserted
A third party that performed the security audit of the entity running the Key Holder systems asserted the Key Extraction Protection level.
Device level attestation
The device used as Key Holder asserted the Key Extraction Protection level.

1.8. Identifiers

AGD_ID

The ADIA Global Directory (AGD) IDentity, i.e. the the W3C DID style identifier for the ADIA Global Directory.

AGD_DA

Human readable Digital Address of the ADIA Global Directory (e.g., adia@adia).

AGD_ID_PK, AGD_ID_SK

Public Key (PK) and Private Key (SK) related to the AGD_ID. See figure Cryptographic Key Material for more details.

ARD_ID

The ADIA Regional Directory (ARD) IDentity, i.e. the the W3C DID style identifier for the ADIA Regional Directory.

ARD_DA

Human readable Digital Address of the ADIA Regional Directory (e.g., acme.eu@adia).

ARD_ID_PK, ARD_ID_SK

Public Key (PK) and Private Key (SK) related to the ARD_ID. See figure Cryptographic Key Material for more details.

AVC

Anonymous Verifiable Credential. This is a special case of a Verifiable Credential when the included claims to not uniquely identify any specific user. For example a credential that just proof the user is older than 21.

DA

Human readable Digital Address of the User (e.g., blackbird.us@dtx).

Note: The DA doesn’t have to include the user’s real name - "fun" names are allowed and recommended. However, real names are still allowed and the ADIA system doesn’t check whether users use them.

DAS_USER_ID

The DAS specific Decentralized Identifier (DID) related to the DA, e.g., did:example:123456789abcdefghi

DAS_USER_ID_PK, DAS_USER_ID_SK

Public Key (PK) and Private Key (SK) related to the DAS_USER_ID. See figure Cryptographic Key Material for more details.

DAA

Digital Address Application, e.g., Android App or iOS App that knows how to talk to the DAS on behalf of the User.

DAS_ID

DAS IDentity, i.e. the W3C DID style identifier for the DAS.

DAS_ID_PK, DAS_ID_SK

Public Key (PK) and Private Key (SK) related to the DAS_ID. See figure Cryptographic Key Material for more details.

DAS_DA

Human readable Digital Address of the Digital Address Service (e.g., dtx@acme.eu).

DID

Decentralized Identifier according to [did-core]

DIDDoc-ISSUER

DID document binding the Issuer’s public key to the ISSUER_ID.

DIDDoc-SP

DID document binding the Service Provider’s public key to the SP_ID.

DIDDoc-DAS

DID document binding the DAS’s public key to the DAS_ID.

DIDDoc-ARD

DID document binding the ADIA Regional Directory’s public key to the ARD_ID.

DIDDoc-AGD

DID document binding the ADIA Global Directory’s public key to the AGD_ID.

DIDDoc-USER

DID document binding the user’s public key to the DAS_USER_ID.

HIDA

Cryptographic hash computed over the ID Attributes

HomeDAS_ID

DAS_ID of the DAS that user primarily belongs to (i.e. HomeDAS).

ID Attributes

Attributes identifying a user uniquely defined by the ADIA Specification

ISSUER_ID

Issuer IDentity, i.e. the DID style identifier for the Issuer.

ISSUER_DA

Human readable Digital Address of the Issuer (e.g., dmv.us@dtx).

ISSUER_ID_PK, ISSUER_ID_SK

Public Key (PK) and Private Key (SK) related to the ISSUER_ID. See figure Cryptographic Key Material for more details.

SP_ID

Service Provider IDentity, i.e. the DID style identifier for the SP.

SP_DA

Human readable Digital Address of the Service Provider (e.g., start.industries.us@dtx).

SP_ID_PK, SP_ID_SK

Public Key (PK) and Private Key (SK) related to the SP_ID. See figure Cryptographic Key Material for more details.

TA_USER_ISSUER

The Issuer specific TA, i.e. hash(TA, ISSUER_ID).

USER_FIDO_PK, USER_FIDO_SK

The FIDO credential owned by the user’s authenticator and used to authenticator to DAS and Cloud Agent. See figure Cryptographic Key Material for more details.

VC

Verifiable Credential, see [vc-data-model].

VC_METADATA

Metadata of a VC, i.e. DID, VC Schema Name, VC Schema Friendly Name

1.9. Trust Model

ADIA Trust Model

When verifying a verifiable presentation of a verifiable credential, the following objects need to be verified:

  1. Verifiable Presentation, i.e. an object containing a Verifiable Credential (example) [vc-data-model] or Derived Data (in the case of ZKP) (example) and a signature by the subjects’s DAS_USER_ID_PK/DAS_USER_ID_SK key.

  2. Verifiable Credential, i.e. an object containing a CredentialSubject, an issuer and a signature by the Issuer’s ISSUER_ID_PK/ISSUER_ID_SK key.

  3. Issuer ISSUER_ID_PK/ISSUER_ID_SK key. This key is linked to the Issuer via the DIDDoc-ISSUER which is signed by the DAS.

    1. Verify the trustworthiness of the DAS by retrieving and verifying the DIDDoc-DAS that was issued by the ARD.

    2. Verify the trustworthiness of the ARD by retrieving and verifying the DIDDoc-ARD that was issued by the AGD.

    3. Verify the trustworthiness of the AGD by retrieving and verifying the DIDDoc-AGD that was issued by the AGD.

    4. As a participant of the ADIA system, you implicitly trust the AGD’s public key AGD_ID_PK.

  4. Subject DAS_USER_ID_PK DAS_USER_ID_SK key. This key is linked to the User via the DIDDoc-USER which is signed by the DAS.

    1. Verify the trustworthiness of the DAS by retrieving and verifying the DIDDoc-DAS that was issued by the ARD.

Note: The Assurance Level to which the various entities have been verified is maintained in field ASSURANCE_LEVEL in the respective Digital Address and in the Credential Metadata.

In the case of Anonymous Verifiable Credentials (e.g., "older than 21"), the DIDDoc-USER is a pair-wise use object and the included DAS_USER_ID_PK is a one-time use key. Pair-wise use means it is not shared with any other SP and it will typically not even be referenced by another verifiable presentation to the same SP again to maintain the user’s privacy.

Key Holder denotes the entity that technically controls the use of the key. Key Owner is the entity the key is attributed to.

Key Name Key Owner Key Holder When Generated How is key tied to Key Owner? How is security level of device maintaining the key attested?
AGD_ID_PK / AGD_ID_SK ADIA Global Directory ADIA Global Directory ADIA setup. via a DIDDoc kept in the ADIA Global Directory. as described in the respective key protection level field § 1.7 Key Protection Level.
ARD_ID_PK / ARD_ID_SK ADIA Regional Directory ADIA Regional Directory ADIA Regional setup. via a DIDDoc kept in the ADIA Global Directory. as described in the respective key protection level field § 1.7 Key Protection Level.
DAS_ID_PK / DAS_ID_SK DAS DAS Agent Onboarding as DAS via a DIDDoc kept in the ADIA Global Directory. as described in the respective key protection level field § 1.7 Key Protection Level.
ISSUER_ID_PK / ISSUER_ID_SK Issuer Issuer Agent Onboarding as an Issuer via a DIDDoc kept in the ADIA Global Directory. as described in the respective key protection level field § 1.7 Key Protection Level.
SP_ID_PK / SP_ID_SK Service Provider SP Agent Onboarding as Service Provider via a DIDDoc kept in the ADIA Global Directory. as described in the respective key protection level field § 1.7 Key Protection Level.
DAS_USER_ID_PK / DAS_USER_ID_SK User Typically the Cloud Agent (potentially the DAA once we specify the device migration) User Onboarding to First Issuer via a DIDDoc kept in the HomeDAS. as described in the respective key protection level field § 1.7 Key Protection Level.
USER_FIDO_PK / USER_FIDO_SK User The User’s FIDO Authenticator, e.g., SecurityKey or platform authenticator on smartphone, tablet or PC. User Onboarding to First Issuer via a DB record stored by the respective HomeDAS. FIDO authenticator attestation according to [WebAuthn] or [UAFProtocol].
Cryptographic Key Material

1.10. Terminology and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] and indicate requirement levels for compliant ADIA implementations.

1.10.1. Sequence Diagrams

A sequence diagram shows object interactions arranged in time sequence. It depicts the objects involved in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the scenario.

The conventions used in these documents to represent interactions between participants is as follows:

Message types in sequence diagrams

2. Operations

This section is not normative.

2.1. Directory enrollment

2.1.1. Enroll a Regional Directory

Regional Directories are onboarded into the ADIA Ecosystem by the ADIA Global Directory. The process starts with the Regional Directory providing their organizational and contact person details to meet the certification criteria established by the ADIA Governance process.

The governing body within the ADIA Global Directory may approve or reject requests to enroll into the ADIA ecosystem. On successful approval of an Entity as a Regional Directory, a provisioning request is sent to the responsible party within the Regional Directory. The process to set up an Agent is beyond the scope of this document but is a necessary prerequisite to enroll the ADIA Regional Agent (ARD Agent).

An ARD Agent generates the public/private key pair for the Entity and requests a Digital Address to be created by the ADIA Global Directory (AGD Agent). A DIDDoc for the ARD with its endpoint details, public keys and any additional information is published to the ADIA Global Directory.

Enrollment into the ADIA Global Directory is complete when the ARD_ID to the Hashed ID attributes (HIDA) of the entity are related in the ADIA Global Directory. A VC is issued by the AGD using information used to verify the ARD.

The following sequence diagram depicts the details of the flow between entities and exchange of messages between Agents.

Note: Details of the Agents and protocol messages are depicted below.

Enroll Regional Directory to Global Directory

2.1.2. Enroll a DAS

Digital Address Services (DASs) are onboarded into the ADIA Ecosystem by the ADIA Regional Directory. The process starts with the DAS providing their organizational and contact person details to meet the certification criteria established by the ADIA Governance process.

The governing body within the ADIA Regional Directory may approve or reject requests to enroll into the ADIA ecosystem. On successful approval of an Entity as a DAS, provisioning request is sent to the responsible party at the DAS. The process to set up an Agent is beyond the scope of this document but is a necessary prerequisite to enroll the DAS Agent to the ADIA Regional Directory.

A DAS Agent generates the public/private key pair for the Entity and requests a Digital Address to be created by the ADIA Regional Directory (ARD Agent). A DIDDoc for the DAS with endpoint details, public keys and any additional information is published to the ADIA Global Directory.

Enrollment into ADIA Global Directory is complete when the DAS_ID to the Hashed ID attributes (HIDA) of the entity are related in the ADIA Global Directory. A VC is issued by the ARD using information used to verify the DAS.

The following sequence diagram depicts the details of the flow between entities and exchange of messages between agents.

Note: Details of the agents and protocol messages are depicted below.

Enroll DAS to Regional Directory

2.1.3. Enroll an Issuer

Issuers are onboarded into the ADIA Ecosystem by a DAS. The process starts with the DAS requiring the prospective Issuer to provide organizational details, a contact person for the organization and details to qualify the Issuer as a member in good business standing, financial status and criteria to meet the Certification process established by the ADIA Governance policies.

The governing body within the DAS may approve or reject requests to enroll into the DAS and the ADIA ecosystem. Successful approval of an Entity as an Issuer results in a Digital Address and a DID (i.e. ISSUER_ID) being created. A VC is issued by the DAS using information used to verify the Issuer. The DAS may also enforce additional policies to ensure that the Issuer can issue Digital Addresses to Users or issue Verifiable Credentials with a certain Assurance Level. Please see § 1.6 Assurance Level for more detail.

In certain deployment models, a DAS may provide the Issuer with an Issuer Agent and a VC Store that comply to the ADIA Specification. Other deployments may provide agency services to provision the Issuer Agents in a hosted model.

Regardless the variances in the deployment model, the Issuer Agent is responsible for creating and managing their private key (ISSUER_ID_SK) and DID (i.e. ISSUER_ID) and enroll with the DAS. The Issuer’s public information such as business name and the DIDDoc-Issuer is published to the ADIA Global Directory for lookups by any entity in the ADIA ecosystem.

Enroll Issuer to a DAS

2.1.4. Enroll a Service Provider

Service Providers are onboarded into the ADIA Ecosystem by a DAS. The process starts with the DAS requiring the prospective Service Provider to provide organizational details, a contact person for the organization and details to join the ecosystem.

The governing body within DAS may approve or reject requests to enroll into the DAS and the ADIA ecosystem. Successful approval of an Entity as an Service Provider results in a Digital Address and a DID (i.e. SP_ID) being created. A VC is issued by the DAS using information used to verify the Service Provider.

The DAS may provide API services or provide agency services to provision the Service Provider Agent in a hosted model to request and verify Verifiable Credentials of Users.

Agent based deployments may require the Service Provider to manage their private key (SP_ID_SK) and DID (i.e. SP_ID) and enroll with the DAS. The Service Provider’s public information such as business name and their DIDDoc-SP is published to the ADIA Global Directory for lookups by any entity in the ADIA ecosystem.

Enroll an SP to DAS

2.1.5. Enroll a User

Users may approach Issuers to create a Digital Address or Issuers may create a Digital Address for a user prior to issuing a Verifiable Credential to that User. Creating a Digital Address starts with the issuer collecting identity attributes of the User and checking the HIDA resulting from the HIDA hashing process against the existing HIDA registry to see if the User is already known to the system.

A lookup of the HIDA may result in the possibility of an existing Digital Address for that User. The User may request to link the existing Digital Address instead of creating a new one. ADIA Governance policies and technical constraints within this specification enforce that the uniqueness of the HIDA for a given User is maintained within the same ADIA Regional Directory.

The DAS related to the first Digital Address provided by an Issuer is called HomeDAS. The HomeDAS also provides services to persist and search the Credential Metadata associated with the Verifiable Credentials issued to the User.

2.1.5.1. Issuer Initiated New User Enrollment

The diagram below represents a new User requesting a Digital Address from an Issuer. The DAS providing the Agency services, provisions a Cloud Agent for the User to create a public/private key pair and a DID (i.e. DAS_usER_ID) for the User. The identifier (DAS_USER_ID), along with the HomeDAS identifier (HomeDAS_ID) are persisted on the DAS to associate their identifiers with the newly created Digital Address. Please refer to the § 1.3 Trust Anchor and § 1.4 Digital Address sections for more details on the representation and usage of the Digital Address.

The Issuer may share the Digital Address with the User through any secure channel. For simplicity, the diagram shows the sharing of Digital Address information encoded in a QR code that can be scanned using the DAA or another method endorsed by this ADIA Specification.

User Onboarding to First Issuer

There are some important steps before the User is allowed to import the Digital Address:

  1. Verifying the User’s Identity
  2. Authenticate the User given the Digital Address
    • The DAS may request the User to register their DAA using FIDO. FIDO provides a strong passwordless authentication for operations such as resenting proof or other operations that require the User’s consent using a biometric or possession based verification mechanism before unlocking the private key for signing functions. Please see the section on § 1.5.7 Digital Address Application (DAA) for more details.
  3. User Consent

Once a Digital Address is acquired by the User, possible subsequent steps are:

2.1.5.2. Enroll a User with existing Digital Address

A User with an existing Digital Address, intentionally or unintentionally may request another Digital Address. The request may be initiated by an Issuer on the same DAS or an Issuer on another DAS within the same ADIA Regional Directory. Within a single ADIA Regional Directory, if the HIDA for the User results in a collision, the User may not request a new Digital Address but instead is notified of the existing one.

User Onboarding to Second Issuer

Note: It is possible for a User to have a different Digital Address in another ADIA Regional Directory.

2.1.5.3. User Initiated New User Enrollment (using DAA)

A User may initiate the creation of a Digital Address remotely, via an online service provided by a Digital Address Issuer. The Issuer’s service must follow procedures similar to the in-person creation by requesting the identity attributes of the User, generating the hashed attributes (HIDA) and verifying against the ADIA Regional Directory.

The online service of the Issuer presents the user with a QR code either online on its website or offline via an email or alternate service channel, such that the User is able to scan the QR code containing their Digital Address information and initiate an Authenticator Binding processes with the HomeDAS.

User Initiated Digital Address Creation with DAA

A successful authentication and binding to the HomeDAS’s services allows the user to use the Digital Address at the Assurance Level determined by the onboarding process. Please see the section on § 1.6 Assurance Level for more information.

Though it may be adequate for some purposes, some Service Providers in the ecosystem may require the User to have a higher Assurance Level. Issuer’s in ADIA may provide verification services for Users to upgrade their Assurance Level assigned by remote methods. This is described in the section § 2.1.5.4 Issuer Assisted Verification of Digital Address.

2.1.5.4. Issuer Assisted Verification of Digital Address

The User may choose to visit a Verification Center in person to upgrade the Assurance Level initially assigned by the system. An in-person verification may include a manual review and verification of their identity documents by a certified operator before reporting to the DAS about the genuineness of the subject.

The DAS may independently request the User to authenticate before upgrading the User’s Assurance Level.

Verify User with Digital Address to upgrade Assurance Level

2.2. Verifiable Credential

2.2.1. Issue Verifiable Credential

Issuers may issue one or more Verifiable Credentials (VC Issuance) to a User who has a Digital Address. A VC contains claim attributes related to the User (Identity VCs) or Data VCs that hold attributes contained within a well-defined and approved Credential Schema. VC Issuance starts with a credential offer presented to the User and the User’s approving the information contained in the VC.

The User signs the VC with their private key and sends the signed VC to the Issuer. The Issuer’s agent persists the VC in its VC Store and notifies the Cloud Agent to persist the VC metadata in the DAS.

VC Issued to a User by an Issuer

Note: An important pre-requisite to this process is that the Credential Schema must be published by an authorized Entity in the Ecosystem. the Credential Schema may be published by the ADIA Global Directory, an ADIA Regional Directory or an Issuer. Protocols described in the Credential Schema Protocol (ADIA-protocol#sctn-credential-schema-protocol) have more details on the supported commands and messages.

2.2.2. Revoke a Verifiable Credential

Issuers may revoke VCs issued to a User. Revoking a VC results in the update of the Credential Metadata on the DAS. The DAS checks for constraints before allowing the revocation of an issued VC. Some of them are:

  1. Issuers may revoke only the VCs issued by them.

  2. The Digital Address of the VC’s subject is valid and not in an invalid state.

  3. The VC is valid and in a non-expired state.

Revoke a VC

The User is notified of the revocation but there is no expectation of an action from the User. Revoked VCs are no longer valid and hence not considered for subsequent proof presentations.

2.2.3. Expire Verifiable Credential

Verifiable Credentials are temporal in nature. Expired credentials are not valid for any proof presentations. A DAS may employ scheduled jobs to scan its Credential Metadata and mark expired Credential Metadata as inactive. Expired Credentials may not be used for Proof Presentations by a User or Cloud Agent.

Expire a VC

Note: The Issuer of the Verifiable Credential must be notified of the expiration. Issuers may follow procedures to deprecate or void credentials issued by them based on local regulatory requirements or policies.

2.3. Present Proof/Verifiable Presentation

The goal of the VC Presentation operation is to allow a user to present identity attributes for themselves to a Service Provider (SP). These attributes are included in the verifiable credential and have been verified by the VC’s Issuer. ADIA employs Verifiable Presentations as defined by [vc-data-model] (https://www.w3.org/TR/vc-data-model/#dfn-verifiable-presentations).

ADIA distinguishes two types of Verifiable Credentials:

  1. Credentials that include sufficient personal identifiable information (PII) to uniquely identify the user (identifying verifiable credentials) and

  2. Credentials that don’t include PII (Anonymous Verifiable Credentials). For example a credential that just states the user is older than 21.

In both cases, a public key is linked to the verifiable credential via the subject’s DID document (see Example #2 in [did-core]). It is used as a proxy for the user, meaning anyone that can prove access to the related private key is assumed to be the user. Consequently, in case (2), the public key - if it is included - will never appear publicly with a link to the user record. Instead, it will be a single-time use key, that is included in order to allow the SP to recognize the subject (user) the attributes relate to.

Please refer to the section on § 1.9 Trust Model for details on how the ISSUER_ID_PK is verified by the Service Provider.

2.3.1. Present Identifying Credentials

Verifiable Presentation and Verification (Option 1)

2.3.2. Present Anonymous Credentials

Note: Presentation of anonymous credentials and Zero-knowledge proofs is a work in progress and will be supported in subsequent versions of this Specification.

Note: In this case, the message to present the Verifiable Credential that is sent from the Cloud Agent to the SP is signed with a dedicated signing key as opposed to being signed with DAS_USER_ID_SK in order to avoid a correlation handle in this operation. This is a deviation from the default use of [didcomm-messaging-v1] that we specify in § 4.6 Protocol Messages.

Anonymous Verifiable Credentials don’t intrinsically expose a link from the credential to a specific user. A key dedicated for this operation is created on-demand by the user’s Cloud Agent. Presentations of the Anonymous Verifiable Credential to different SPs will trigger the use of different keys to avoid the exposure of a correlation handle.

Verifiable Presentation and Verification (Option 2: Anonymous)

2.4. User Consent

User consent for actions must be accomodated. The consent should be collected via the Digital Address Application. Authentication should be performed using FIDO.

2.5. Device Management

2.5.1. Bootstrap a New DAA Instance

The User MAY bootstrap a new DAA on the new smartphone - without having access to the old DAA instance. This is useful if the User has lost his/her device and does not have access to their old device. Bootstraping a new instance of DAA requires the steps to ID proof the user on the new device.

Please see § 2.5.4 Delegated Recovery to recover the DA without the ID proofing process.

User Bootstraps New DAA Instance "Lost Phone"

2.5.2. Bootstrap Additional DAA Instance

The User MAY bootstrap additional devices for the same Digital Address. This assumes that the User is still in control or possession of their old DAA instance. ID proofing is not required in such cases but the User MUST authenticate and register the new DAA instance with the DAA.

User Bootstraps Additional DAA Instance "New Phone"

2.5.3. Recover Digital Address

Users have the ability to recover a forgotten Digital Address in several ways such as, recovering from a backup device or a delegated recovery using other trusted third parties.

2.5.3.1. Self-Recovery

One of the most common ways to recover a Digital Address is similar to the process of bootstrapping a new device. The User may either use an Issuer’s online service to provide Identity Attributes originally provided to generate the HIDA. The ID Proofing MUST be performed to validate the User’s identity.

Please see § 2.5.1 Bootstrap a New DAA Instance

2.5.3.2. Email-based Recovery

In some enterprise use cases, an Issuer may provide services for Users to recover Digital Addresses and provide existing identity proofing methods within their enterprise versus the DAS. This may be more relevant in cases of recovering a Digital Address.

Note: Email based recovery may expose additional attributes to the DAS to enable convenience as a tradeoff over privacy considerations.

Email based recovery

2.5.4. Delegated Recovery

Users can recover access to their prior credentials by either enabling a back up device or using one or more trusted delegatees who also have a Digital Address. Once a Digital Address is recovered, all Verifiable Credentials issued to the Digital Address are available to the User with the same Assurance Level for Presentation to Service Providers.

2.5.4.1. Delegated Recovery with a Trusted Peer

If the delegatee is a trusted person, such as a family member or a nominated friend, recovery of the Digital Address and credential metadata is possible using a peer mode by directly scanning a QR code from the delegatee’s device.

Delegated Recovery Peer Mode
2.5.4.2. Delegated Recovery with multiple delegatees

The User may choose to nominate several delegatees. This is enabled with a recovery code generated by the DAS for the given transaction. DASs may enforce constraints such as accepting successful responses from 3 out of 5 nominees, to validate the acceptance criteria before granting access to the User’s recovered metadata. Once a Digital Address is recovered, all Verifiable Credentials issued to the Digital Address are available to the User with the same Assurance Level for Presentation to Service Providers.

Delegated Recovery Multiple Delegatees

2.5.5. Delete Digital Address

The User acquires the Digital Address and Verifiable Credentials through their lifetime in the ADIA ecosystem § 1.2 Ecosystem Overview. Relationships of the User with other entities, such as Issuers and Service Providers are maintained by the DAS. In some cases however, the User may choose to terminate their relationship with a DAS or the ADIA ecosystem entirely.

The process may be initiated by the User or in some cases such as the Issuer of the first Digital Address voiding the Digital Address due to a procedural or data entry error.

2.5.5.1. User Initiated
User Initiated Account Deletion

Note: Notification of issuers is as an optional step from a technical perspective. The ADIA Governance and retention policies define the details of this.

Note: Deletion of VCs related to this Digital Address is defined in the ADIA Governance and retention policies.

2.5.5.2. Issuer Initiated

The Issuer may initiate a Digital Address that is not completely claimed by the User. This would be in case of an error by the Issuer or the User’s desire not to be part of the ADIA ecosystem.

In such cases, an Issuer may initiate deletion of the Digital Address only if:

Issuer Initiated Account Deletion

2.6. DAS-to-DAS Communication

ADIA ecosystem is a network of networks comprising of many DASs connecting Issuers, Service Providers and Users to seamlessly issue VCs and verify VCs issued by Issuers. This however means thatt these entities may be within the same network or enrolled in different DASs.

The protocol discusses discovery of the User’s HomeDAS to look up the Credential Metadata, resolve the appropriate Issuers, and securely respond to the Service Provider with the Verifiable Presentation. DAS-to-DAS protocols are specifically designed to enable interoperability between DAS that may choose to implement their internal agent-to-agent communication in a different style, but rely on the DAS to form a mesh of services that abstract the details of external communication.

To facilitate routing, it is assumed that the enrollment of the DAS results in a network broadcast to all other DASs in the ecosystem, or alternatively, access to route tables that enable one DAS to resolve the location of another DAS. The implementation of the route tables is not discussed in this specification. Please see the section on § 2.1.2 Enroll a DAS for more details.

The sections below presents variants in the communication flows and how these entities exchange VCs using DIDComm.

2.6.1. Scenario 1

As represented in the figure below,

Users and Issuers in the same DAS. Service Provider in a different DAS
2.6.1.1. Issue Credential

Since the Issuer and User are in the same network, this is a the same operation as § 2.2.1 Issue Verifiable Credential.

2.6.1.2. Verify Credential

To verify a VC, the Service Provider resolves the User’s HomeDAS from the Digital Address or the User’s DID. The Service Provider must then discover the endpoint for the HomeDAS so that Credential Metadata lookups can be made. The SP’s HomeDAS establishes a DIDComm connection with the User’s HomeDAS. The HomeDAS or the Cloud Agent of the User retrieves the VC from the Issuer (also see § 2.3 Present Proof/Verifiable Presentation).

The User’s Cloud Agent routes the Presentation to the SP via the SP’s HomeDAS. Further detail on the encryption, discovery and routing of the messages is represented below.

Verify VC: Users and Issuers in the same DAS. Service Provider in a different DAS

2.6.2. Scenario 2

As represented in the figure below,

Users and Service Provider in the same DAS. Issuers in a different DAS
2.6.2.1. Issue Credential

To issue a VC, the Issuer resolves the User’s HomeDAS from the Digital Address or the User’s DID. The Issuer must then discover the endpoint for the HomeDAS so that Credential Metadata lookups can be published. The Issuer’s HomeDAS establishes a DIDComm connection with the User’s HomeDAS. The the Cloud Agent of the User saves the VC metadata from the Issuer (also see § 2.2.1 Issue Verifiable Credential).

The User’s Cloud Agent routes the response via the Issuer’s HomeDAS. Further detail on the encryption, discovery and routing of the messages is represented below.

Issue VC: Users and Service Provider in the same DAS. Issuers in a different DAS
2.6.2.2. Verify Credential

To verify a VC, the Service Provider resolves the User’s HomeDAS, which is the same, DAS1, from the Digital Address or the User’s DID. The Service Provider must then discover the endpoint for the HomeDAS so that Credential Metadata lookups can be made. The SP’s HomeDAS establishes a DIDComm connection with the User’s HomeDAS.

For VCs issued by an Issuer in a different network, the User’s HomeDAS establishes a DIDComm connection with the Issuer’s DAS. For VCs issued by Issuer’s in the User’s HomeDAS, a discovery is not required. The HomeDAS or the Cloud Agent of the User retrieves the VC from the Issuer (also see § 2.3 Present Proof/Verifiable Presentation).

The Cloud Agent routes the Presentation to the SP via the SP’s HomeDAS. Further detail on the encryption, discovery and routing of the messages is represented below.

Verify VC: Users and Service Provider in the same DAS. Issuers in a different DAS

2.6.3. Scenario 3

As represented in the figure below,

Users in One DAS. Issuers and Service Provider in a different DAS
2.6.3.1. Issue Credential

Since the Issuer and User are in different networks, the flow is the same as § 2.6.2.1 Issue Credential.

2.6.3.2. Verify Credential

To verify a VC, the Service Provider resolves the User’s HomeDAS, in this case, DAS1, from the Digital Address or the User’s DID. The Service Provider must then discover the endpoint for the HomeDAS so that Credential Metadata lookups can be made. The SP’s HomeDAS establishes a DIDComm connection with the User’s HomeDAS.

For VCs issued by an Issuer in a different network, the User’s HomeDAS establishes a DIDComm connection with the Issuer’s DAS. For VCs issued by Issuer’s in the User’s HomeDAS, a discovery is not required. The HomeDAS or the Cloud Agent of the User retrieves the VC from the Issuer (also see § 2.3 Present Proof/Verifiable Presentation).

The Cloud Agent routes the Presentation to the SP via the SP’s HomeDAS. Further detail on the encryption, discovery and routing of the messages is represented below.

Verify VC: Users in One DAS. Issuers and Service Provider in a different DAS

2.6.4. Scenario 4

Scenario 4 presents a more complicated yet realistic scenario for a network-of-networks ecosystem such as ADIA. As represented in the figure below,

Users in One DAS. Issuers and Service Provider in a different DAS
2.6.4.1. Issue Credential

Since the Issuer and User are in different networks, the flow is the same as § 2.6.2.1 Issue Credential.

2.6.4.2. Verify Credential

To verify a VC, the Service Provider resolves the User’s HomeDAS, in this case, DAS1, from the Digital Address or the User’s DID. The Service Provider must then discover the endpoint for the HomeDAS so that Credential Metadata lookups can be made. The SP’s HomeDAS establishes a DIDComm connection with the User’s HomeDAS.

For VCs issued by an Issuer in a different network, the User’s HomeDAS establishes a DIDComm connection with the Issuer’s DAS. For VCs issued by Issuer’s in the User’s HomeDAS, a discovery is not required. The HomeDAS or the Cloud Agent of the User retrieves the VC from the Issuer (also see § 2.3 Present Proof/Verifiable Presentation).

The Cloud Agent routes the Presentation to the SP via the SP’s HomeDAS. Further detail on the encryption, discovery and routing of the messages is represented below.

Verify VC: Users, Issuers and Service Provider in different DASs

3. Data Schema

This section is normative.

3.1. Data Residency

In ADIA ecosystem, User and Entity information resides at the respective sources, for example, User’s identity information resides in the Issuer’s system, Digital Address metadata resides at the DAS, and so on. This is aligned with the core principle that the DAS and other relevant entities route information flows but the User and Issuers maintain control and access to information. This is represented by the diagram below:

Data Residency

Regional and Global Directories MUST support:

DAS Directories MUST support:

3.2. Entity Model

The following diagram depicts a logical view of an entity in ADIA.

Entity Model

3.2.1. Trust Anchor

Name Type Description
TA String Unique and Opaque string (UUID). See § 1.3 Trust Anchor
ENTITY_ID String DID of the entity
ENTITY_PARENT_ID String DID of the either HomeDAS (HomeDAS_ID) or Home ARD (HomeARD_ID)
CREATED_BY String DID of the creator - person or entity
CREATE_DATE DateTime ISO 8601 format

3.2.2. Digital Address

Name Type Description
TA String Trust Anchor Reference. See § 3.1 Data Residency
ENTITY_ID String DID of the entity
ENTITY_DIGITAL_ADDRESS String Digital Address
ENTITY_ROLE Enum
  • Issuer
  • ServiceProvider
  • DAS
  • RegionalDirectory
HIDA String
ISSUER_ID String DID of the Issuing entity
ISSUER_DA String Digital Address of the Issuing entity
CONSENT_IND Boolean Indicator whether the entity provided consent to create this Digital Address
CONSENTED_BY String DID of the consenting entity
CONSENTED_DATE String ISO 8601 format
ASSURANCE_LEVEL

This assurance level is related to the User, see § 1.6.2 User Assurance Level.

Enum
  • U-AL1
  • U-AL2
  • U-AL3
STATUS Enum
  • Active
  • Pending
  • Inactive
CREATED_BY String DID of the creator - person or entity
CREATE_DATE DateTime ISO 8601 format

3.2.3. Credential Metadata

The ADIA system maintains the following fields as Credential Metadata.

Name Type Description
ENTITY_ID String DID of the entity
ENTITY_DIGITAL_ADDRESS String Digital Address
ISSUER_ID String DID of the Issuing entity
ISSUER_DA String Digital Address of the Issuing entity
CREDENTIAL_SCHEMA_ID String Identifier of the Credential Schema against which the VC was issued
CREDENTIAL_SCHEMA_VERSION String Version of the Credential Schema against which the VC was issued
CREDENTIAL_TYPE Enum
  • IDENTITY_VC
  • DATA_VC
  • CUSTOM_VC
ASSURANCE_LEVEL

This assurance level is related to the Verifiable Credential, see § 1.6 Assurance Level.

Enum
  • VC-AL1
  • VC-AL2
  • VC-AL3
STATUS Enum
  • Active
  • Pending
  • Inactive
CREATED_BY String DID of the creator - person or entity
CREATE_DATE DateTime ISO 8601 format

3.2.4. Credential Schema

Name Type Description
SCHEMA_NAME String Name of the Credential Schema
VERSION String Version of the Credential Schema
DESCRIPTION String Usability and applicability of the Credential Schema
PUBLISHED Boolean Indicator whether the schema has been published
PUBLISHED_DATE String ISO 8601 format
PUBLISHED_BY String DID of the Entity publishing the Credential Schema
SCHEMA_LEDGER_ID String Id of the Credential Schema on the Ledger
CREATED_BY String DID of the creator - person or entity
CREATE_DATE DateTime ISO 8601 format

3.2.5. Credential Schema Attribute

Name Type Description
CREDENTIAL_SCHEMA_ID String Reference to the Credential Schema
NAME String Name of the Attribute
TITLE String Display Title (may be different from the Name)
DATATYPE Enum
  • Text
  • Boolean
  • Date
  • Number
  • Blob
ORDER_VALUE Integer Sorting order for display purposes
CREATED_BY String DID of the creator - person or entity
CREATE_DATE DateTime ISO 8601 format

3.3. Verifiable Credentials

ADIA messaging relies on the W3C Standards, especially the Verifiable Credentials Data Model. Some of the data elements from W3C and their relevance is mentioned below:

3.3.1. Credential Schema

Note: Please see Verifiable Credentials JSON Schema Specification for the information on Credential Schema.

In ADIA, Verifiable Credentials maybe issued by an Issuer, a DAS, an ARD or the AGD. By adhering to schemas such as an Identity Schema or a Data Schema, the structure of the claims within a Verifiable Credential may be packaged, signed and verified by an Agent (e.g. Issuer Agent or Service Provider Agent) within the ecosystem. For the version of this specification, as described in the § 6.1 Cryptographic Algorithms, agents may use Ed25519 signature algorithm for VC payload signing.

Please see § 3.2.4 Credential Schema and § 3.2.5 Credential Schema Attribute for detailed description of the schema.

3.3.2. DID Document

DID Documents (DIDDocs) bind attributes to a DID [did-core]. DIDDocs are signed objects. See § 1.9 Trust Model for an overview of the DIDDocs.

See § 6.1 Cryptographic Algorithms for details on suitable cryptographic algorithms.

Format

{
    // JSON-LD context
    "context": "https://www.w3.org/ns/did/v1",
    // DID of the subject
    "id": "did:dtx:z6MkiCRKXdK9TdMfa2BbgooBUUGs9NZNWdsM6DPbai2PKfNf",
    // entity that is authorized to make changes to a DID document
    "controller": ["did:dtx:z6MkiCRKXdK9TdMfa2BbgooBUUGs9NZNWdsM6DPbai2PKfNf"],
    //
    "verificationMethod": [{
        "id": "did:dtx:z6MkiCRKXdK9TdMfa2BbgooBUUGs9NZNWdsM6DPbai2PKfNf",
        "controller": "did:dtx:z6MkiCRKXdK9TdMfa2BbgooBUUGs9NZNWdsM6DPbai2PKfNf",
        "type": "Ed25519VerificationKey2018",
        "publicKeyBase58": "4kAGwP4i85sCTXLu1EqLdNisKoHX6kczQCUfkS4NQSbH"
    }]
}

In ADIA, the controller represents the Entity that can modify the DIDDoc and an authoritative source that created the DID for an Entity. To maintain the trust relationships in ADIA, the following is recommended:

In addition, there are a few custom attributes that assert the protection and control of cryptographic keys :

Note: To support interoperability with other DID methods, custom attributes need to be registered with the DID Specification Registry. Details of the process can be found at DID Specification Registration Process.

3.3.3. Sample - VC Issuance Payload

A sample VC issued by an Issuer Agent during the § 2.2.1 Issue Verifiable Credential.

{
    "schema_id": "did:key:z6MkpD8tURngJVkoiU9fXQWVRC1LPGJ67pWUTQkBfnPZnVRw:Verified Person:1.5",
    "cred_def_id": "did:key:z6MkpD8tURngJVkoiU9fXQWVRC1LPGJ67pWUTQkBfnPZnVRw:jws:key:z6MkpD8tURngJVkoiU9fXQWVRC1LPGJ67pWUTQkBfnPZnVRw:Verified Person",
    "values": {
        "phoneNumber": {
            "raw": "+1-(251)-6767536",
            "encoded": "66122917157518585820719936268683653982832887950323503352856352801433954245924"
        },
        "dateExpiresEpoch": {
            "raw": "null",
            "encoded": "52530672535577884712458350945238153986666188697374769927409463847120313432331"
        },
        "issuedByName": {
            "raw": "DMV",
            "encoded": "96340665277998983134151122749808737025595883296486667198623365285732970452973"
        },
        "photo": {
            "raw": "null",
            "encoded": "52530672535577884712458350945238153986666188697374769927409463847120313432331"
        },
        "yearOfBirth": {
            "raw": "1994",
            "encoded": "1994"
        },
        "issuedOnBehalfOfName": {
            "raw": "null",
            "encoded": "52530672535577884712458350945238153986666188697374769927409463847120313432331"
        },
        "firstName": {
            "raw": "Chloe",
            "encoded": "54559560339387537378060888887716436642580080746776003585710034788279861161925"
        },
        "verificationSource": {
            "raw": "null",
            "encoded": "52530672535577884712458350945238153986666188697374769927409463847120313432331"
        },
        "dateExpiresISO": {
            "raw": "null",
            "encoded": "52530672535577884712458350945238153986666188697374769927409463847120313432331"
        },
        "lastName": {
            "raw": "Decker",
            "encoded": "10969738818260575036430793428023405595845093806132614190152400232269276501766"
        },
        "email": {
            "raw": "cdecker@hotmail.com",
            "encoded": "111585715190769330326636706969269166508187306508177711136065347571445486183356"
        },
        "dateOfBirth": {
            "raw": "05-05-1994",
            "encoded": "50273734281068575874107310736992418159758183436835273349941361953901111346023"
        },
        "dateIssuedISO": {
            "raw": "03/16/2021 16:26:22",
            "encoded": "4599023557180409009204137715890338923578032198311607639399286188405630050920"
        },
        "dateIssuedEpoch": {
            "raw": "1615892182",
            "encoded": "1615892182"
        }
    },
    "signature": "59nTycBn22T648daQW8U149eP9bKXX3BoXAWV1aj7R2wfqpjWYBymn8WTHfkfDbCaMscSpitjyRAupon19Nxui3V "
}

3.3.4. Sample - Proof Request Payload

A sample of the Proof request requested from the SP Agent to the Cloud Agent

"requestJson": {
    "name": "verifyVerifiedPerson",
    "version": "1.0",
    "nonce": "7824654321",
    "requested_attributes": {
        "one": {
            "names": ["firstName", "lastName"],
            "restrictions": [{
                "schema_id": "did:key:z6MkpD8tURngJVkoiU9fXQWVRC1LPGJ67pWUTQkBfnPZnVRw:Verified Person:1.5",
            }]
        },
    },
    "requested_predicates": {
    "additionalProp2": {
      "name": "yearOfBirth",
      "p_type": "<",
      "p_value": "2000",
      "restrictions": [{
        "cred_def_id": "did:dtx:z6Mkq2oarKt4J261eD1DPqXMnTp9SHVQmqtMHerhAww2xBVu:jws:Covid-19 report:1.0:Covid19"
      }]
    }
  }
}

3.3.5. Sample - Proof Verification Payload

A sample of the Verifiable Presentation generated by the Cloud Agent and presented to the Service Provider.

The SP Agent may then verify the signed VC and the Issuer’s public key.

{
    "proof ": {
        "proofs": {
            "one": {
                "schema_id": "did:key:z6MkpD8tURngJVkoiU9fXQWVRC1LPGJ67pWUTQkBfnPZnVRw:Verified Person:1.5",
                "cred_def_id": "did:key:z6MkpD8tURngJVkoiU9fXQWVRC1LPGJ67pWUTQkBfnPZnVRw:jws:key:z6MkpD8tURngJVkoiU9fXQWVRC1LPGJ67pWUTQkBfnPZnVRw:Verified Person",
                "values": {
                    "phoneNumber": {
                        "raw": "+1-(251)-6767536",
                        "encoded": "66122917157518585820719936268683653982832887950323503352856352801433954245924"
                    },
                    "dateExpiresEpoch": {
                        "raw": "null",
                        "encoded": "52530672535577884712458350945238153986666188697374769927409463847120313432331"
                    },
                    "issuedByName": {
                        "raw": "DMV",
                        "encoded": "96340665277998983134151122749808737025595883296486667198623365285732970452973"
                    },
                    "photo": {
                        "raw": "null",
                        "encoded": "52530672535577884712458350945238153986666188697374769927409463847120313432331"
                    },
                    "yearOfBirth": {
                        "raw": "1994",
                        "encoded": "1994"
                    },
                    "issuedOnBehalfOfName": {
                        "raw": "null",
                        "encoded": "52530672535577884712458350945238153986666188697374769927409463847120313432331"
                    },
                    "firstName": {
                        "raw": "Chloe",
                        "encoded": "54559560339387537378060888887716436642580080746776003585710034788279861161925"
                    },
                    "verificationSource": {
                        "raw": "null",
                        "encoded": "52530672535577884712458350945238153986666188697374769927409463847120313432331"
                    },
                    "dateExpiresISO": {
                        "raw": "null",
                        "encoded": "52530672535577884712458350945238153986666188697374769927409463847120313432331"
                    },
                    "lastName": {
                        "raw": "Decker",
                        "encoded": "10969738818260575036430793428023405595845093806132614190152400232269276501766"
                    },
                    "email": {
                        "raw": "cdecker@hotmail.com",
                        "encoded": "111585715190769330326636706969269166508187306508177711136065347571445486183356"
                    },
                    "dateOfBirth": {
                        "raw": "05-05-1994",
                        "encoded": "50273734281068575874107310736992418159758183436835273349941361953901111346023"
                    },
                    "dateIssuedISO": {
                        "raw": "03/16/2021 16:26:22",
                        "encoded": "4599023557180409009204137715890338923578032198311607639399286188405630050920"
                    },
                    "dateIssuedEpoch": {
                        "raw": "1615892182",
                        "encoded": "1615892182"
                    }
                },
                "signature": "59nTycBn22T648daQW8U149eP9bKXX3BoXAWV1aj7R2wfqpjWYBymn8WTHfkfDbCaMscSpitjyRAupon19Nxui3V"
            }
        }
    },
    "identifiers": [{
        "schema_id": "did:key:z6MkpD8tURngJVkoiU9fXQWVRC1LPGJ67pWUTQkBfnPZnVRw:Verified Person:1.5",
        "cred_def_id": "did:key:z6MkpD8tURngJVkoiU9fXQWVRC1LPGJ67pWUTQkBfnPZnVRw:jws:key:z6MkpD8tURngJVkoiU9fXQWVRC1LPGJ67pWUTQkBfnPZnVRw:Verified Person"
    }]
}

4. ADIA Protocol

This section is normative.

4.1. Complete Protocol Reference

Please see ADIA Protocol Reference Documentation for the detail on protocol commands and sample messages.

4.2. Digital Address Format

As described in section § 1.4 Digital Address, a Digital Address is a user friendly mnemonic with a prefix and a suffix.

The prefix has the following constraints:

The suffix:

Example: steve007@MRVL

4.3. HIDA Computation

This section is normative.

The HIDA is a cryptographic hash computed over the ID Attributes of a User or an Organizational Entity such as the AGD, an ARD, an Issuer, or a SP. The HIDA is a key driver for performing lookup operations to ensure that no two participants have the same Digital Address. Agents that compute the HIDA are typically the ones that have access to the participant’s ID attribute, either through a data entry, scan operation or a connector to the system of record. Agents MUST discard the HIDA after completion of a user operation to ensure that the identifying attributes are not exposed to any kind of attack or correlation to the actual participant.

Please see section § 3.1 Data Residency to understand where the HIDA is stored and its linkage to other identifiers in the ecosystem.

4.3.1. HIDA for Users

The Hash over Identity Attributes (HIDA) is computed as follows:

  1. Compute a JSON object [JSON] containing the following fields:
    firstName
    UTF8 encoded firstname of the User according to the ID document (all uppercase).
    lastName
    UTF8 encoded last name of the User according to the ID document (all uppercase).
    birthDate
    Date of birth of the User according to the ID document. Encoding MUST be full-date as specified by [RFC3339].
    countryOfResidence
    Country of residence of the User according to the ID document. Encoding MUST be ALPHA-2 country code as specified by [ISO3166].
    sourceType
    Type of the ID document. This is specified by ADIA Governance for each country.
    identifier
    Government Issued National Identifier - SSN, Resident ID, Aadhaar ID, etc.
  2. Canonicalize the resulting JSON structure according [RFC8785].
  3. Compute a hash value of the string that results from the previous step.
  4. Construct the resulting HIDA JSON object with just two fields:
    alg
    Name of the hash algorithm used (all uppercase, e.g. SHA256). Allowed hash algorithms are specified in the ADIA Governance and Certification rules.
    hida
    The Base64 encoded [RFC4648] hash value resulting from the previous step.

Please see HIDA for Users for more details.

4.3.2. HIDA for Organizational Entities

The Hash over Identity Attributes (HIDA) is computed as follows:

  1. Compute a JSON object [JSON] containing the following fields:
    businessName
    UTF8 encoded business name of the Entity according to the ID document (all uppercase).
    countryOfIncorporation
    Country of Incorporation of the User according to the ID document. Encoding MUST be ALPHA-2 country code as specified by [ISO3166].
    dateOfIncorporation
    Date of Incorporation of the Organizational Entity according to the ID document. Encoding MUST be full-date as specified by [RFC3339].
    sourceType
    Type of the ID document. This is specified by ADIA Governance for each country.
    identifier
    Government Issued Identifier - Federal Tax ID Number/EIN, Taxpayer Identification Number (TIN), VAT Number, etc.
  2. Canonicalize the resulting JSON structure according [RFC8785].
  3. Compute a hash value of the string that results from the previous step.
  4. Construct the resulting HIDA JSON object with just two fields:
    alg
    Name of the hash algorithm used (all uppercase, e.g. SHA256). Allowed hash algorithms are specified in the ADIA Governance and Certification rules.
    hida
    The Base64 encoded [RFC4648] hash value resulting from the previous step.

Please see HIDA for organizational entities for more details.

4.4. Protocols Categories

All interactions between entities is facilitated through agents and services in the entity’s domain.

Agents manage the participant’s connections with services by implementing protocols to establish connections, perform DID exchanges, issue credentials and present proofs. The ADIA protocols are:

Name Version Protocol Code Description
Digital Address Protocol 1.0 ADIA-DA Create, revoke and share Digital addresses
Directory Protocol 1.0 ADIA-DR Request, approve and onboard trusted entities to the ecosystem
Credential Schema Protocol 1.0 ADIA-CS Create, publish and discover credential schema for VC issuance
Credential Protocol 1.0 ADIA-CR Extensions to the DIDComm issue-credential protocol to issue, revoke and expire VCs to entities
Verification Protocol 1.0 ADIA-VP Extensions to the DIDComm Verifiable Presentation protocol to request, forward and present proofs

4.5. Agent Types

The agents for Issuers and Service Providers implement protocols for establishing connection and perform exchanging DIDs, Credentials and Proofs requests.

There are six types of ADIA agents:

  1. ADIA Global Directory Agent (AGD Agent)

  2. ADIA Regional Directory Agent (ARD Agent)

  3. DAS Agent

  4. Issuer Agent

  5. Service Provider Agent (SP Agent)

  6. Cloud Agent/ User Agent

In accordance with the overall ecosystem, ADIA agents are permitted to interactions with only certain entities. A two-way trust is mandatory to enable interactions between them. This is represented in the table below:

Agent/Agent AGD Agent ARD Agent DAS Agent Issuer Agent SP Agent Cloud Agent
AGD Agent
X
ARD Agent
X
X
DAS Agent
X
X
X
X
Issuer Agent
X
X
SP Agent
X
X
Cloud Agent
X
X
X

4.6. Protocol Messages

The ADIA Protocol messages are an extension of the DIDComm messages [didcomm-messaging-v1].

Each entity’s Agent holds cryptographic keys and digital credentials on behalf of the entity.

Unless mentioned otherwise, each of the protocol messages uses the "Encrypted" envelope level using the "Signed and encrypted" option [didcomm-messaging-v1].

Entity Signature Key Encryption Key
AGD AGD_ID_SK AGD_ID_PK
ARD ARD_ID_SK ARD_ID_PK
DAS DAS_ID_SK DAS_ID_PK
Issuer ISSUER_ID_SK ISSUER_ID_PK
SP SP_ID_SK SP_ID_PK
User DAS_USER_ID_SK DAS_USER_ID_PK

4.6.1. ADIA Functions

The mapping below represents the functions implemented by agents as part of a standard DIDComm protocol [[!DIDCOMM-MESSAGING-V1]}. These functions may be used as co-protocols to perform ADIA specific operations.
Endpoint Code Description AGD Agent ARD Agent DAS Agent Issuer Agent SP Agent Cloud Agent
/credential/1.0/user-hida ADIA-FN-001 A computation of a Hash of ID attributes for a User
X
X
/credential/1.0/entity-hida ADIA-FN-002 A computation of a Hash of ID attributes for an Entity
X
X
X
X
X
/credential/1.0/save-metadata ADIA-FN-003 Save the Credential Metadata to a Directory
X
X
X
/credential/1.0/search-metadata ADIA-FN-005 Search for Credential Metadata based on multiple criteria
X
X
X
/credential/1.0/remove-metadata ADIA-FN-006 Remove the Credential Metadata
X
X
X

4.6.2. Digital Address Protocol

The mapping below represents the protocol messages for the Digital Address Protocol and the agents that implement the handing of these messages. An agent may implement the handler or delegate to another agent for handling via a forward or a relay method.
Endpoint Code Description AGD Agent ARD Agent DAS Agent Issuer Agent SP Agent Cloud Agent
/digital-address/1.0/create-digital-address ADIA-DA-001 Create a Digital Address for an Entity or a User
X
X
X
X
X
/digital-address/1.0/verify-user ADIA-DA-002 Create a Digital Address for an Entity or a User
X
X
X
X
/digital-address/1.0/revoke-digital-address ADIA-DA-003 Revoke a Digital Address for an Entity or User
X
X
X
X
X
/digital-address/1.0/resolve-digital-address ADIA-DA-004 Resolve the DID for an Entity from its Digital Address and vice-versa
X
X
X
X
X
X
/digital-address/1.0/provision-agent ADIA-DA-005 Provision an agent for an Entity
X
X

4.6.3. Directory Protocol

The mapping below represents the protocol messages for the Directory Protocol and the agents that implement the handing of these messages. An agent may implement the handler or delegate to another agent for handling via a forward or a relay method.
Endpoint Code Description AGD Agent ARD Agent DAS Agent Issuer Agent SP Agent Cloud Agent
/directory/1.0/lookup-trust-anchor ADIA-DR-001 Lookup an entity with its Hashed attributes
X
X
X
X
/directory/1.0/enroll-entity ADIA-DR-002 Enroll an Entity into the Directory
X
X
X
X
/directory/1.0/disenroll-entity ADIA-DR-003 Remove an Entity from the Directory
X
X
X
X
/directory/1.0/search-entity ADIA-DR-004 Search an Entity with multiple criteria
X
X
X
X
X
X

4.6.4. Credential Schema Protocol

The mapping below represents the protocol messages for the Credential Schema Protocol and the agents that implement the handing of these messages. An agent may implement the handler or delegate to another agent for handling via a forward or a relay method.
Endpoint Code Description AGD Agent ARD Agent DAS Agent Issuer Agent SP Agent Cloud Agent
/credential-schema/1.0/publish ADIA-CS-001 Publish a Credential Schema
X
X
X
X
/credential-schema/1.0/update ADIA-CS-002 Update a Credential Schema
X
X
X
X
/credential-schema/1.0/search ADIA-CS-003 Search for a Credential Schema based on multiple criteria
X
X
X
X
/credential-schema/1.0/archive ADIA-CS-004 Archive a Credential Schema from active issuance of credentials
X
X
X
X

4.6.5. Credential Protocol

The mapping below represents the protocol messages for the Credential Protocol and the agents that implement the handing of these messages. An agent may implement the handler or delegate to another agent for handling via a forward or a relay method.
Endpoint Code Description AGD Agent ARD Agent DAS Agent Issuer Agent SP Agent Cloud Agent
/credential/1.0/request-signature ADIA-CR-001 Send a VC and request signing
X
X
X
X
/credential/1.0/send-signed-vc ADIA-CR-002 Sign and send the VC to issuing agent
X
X
X
X
X
X
/credential/1.0/revoke-vc ADIA-CR-003 Revoke a VC
X
X
X
X
/credential/1.0/expire-vc ADIA-CR-004 Expire Credential Metadata and Notify User
X
X
X

4.6.6. Verification Protocol

The mapping below represents the protocol messages for the Credential Protocol and the agents that implement the handing of these messages. An agent may implement the handler or delegate to another agent for handling via a forward or a relay method.
Endpoint Code Description AGD Agent ARD Agent DAS Agent Issuer Agent SP Agent Cloud Agent
/credential/1.0/request-consent ADIA-VP-001 Request user for consent to verify a credential
X
X
X
X
X
/credential/1.0/receive-consent ADIA-VP-002 Receive a consent from the User
X
X
X
X
/credential/1.0/request-vc ADIA-VP-003 Request a VC from an Issuer
X
X
X
X
/credential/1.0/verify-vc-claims ADIA-VP-004 Verify each claim within a Presentation
X
X
X
X

5. Considerations

This section is not normative.

5.1. Security Considerations

5.2. Privacy Considerations

6. Certification

This section is not normative.

6.1. Cryptographic Algorithms

The ADIA system makes use of various cryptographic functions. The following crptographic algorithms are relevant.

Algorithm Relevance Purposes
SHA-256 [fips-180-4] Required Compute HIDA, part of cryptographic signature computation and verification
SHA-512 [fips-180-4] Recommended Compute HIDA, part of cryptographic signature computation and verification
ES256 [rfc8152] Required Compute and verify cryptographic signatures
Ed25519 [rfc8032] Required Compute and verify cryptographic signatures
Ed448 [rfc8032] Recommended Compute and verify cryptographic signatures
X25519 [rfc8418] Required Key agreement
Cryptographic Algorithms

6.2. Directories

6.2.1. Hashed Attributes

Directories may be public or privacy preserving. Privacy preserving directories must store hashed attributes and accept hashed attribute queries (as opposed to storing attributes in the clear). This prevents the directory from directly knowing the attributes involved. Public directories on the other hand may use hashed attributes to uniquely identify a participant but they also store data in clear text to enable search queries.

For example, public directories are good for listing company information while private directories are good for users where the identity is not voluntarily disclosed.

ADIA Global Directory is a public directory for Issuers, Service Providers, DAS and ADIA Regional Directories. The ADIA Regional Directory is a private directory for uniquely identifying Users.

6.2.2. Logging

6.2.3. Storage

Whether it is on-chain or off-chain data, the regulatory obligations, for example, GDPR or CCPA, and the "Right to be forgotten" objectives must be met.

6.3. ADIA Regional Directory Certification

An ADIA Regional Directory MUST:

6.4. DAS Certification

A DAS MUST:

6.5. Issuer Certification

An Issuer MUST:

An Issuer MAY:

6.6. Service Provider Certification

A Service Provider MUST:

7. Appendix

This section is not normative.

7.1. ADIA Requirements

Please see ADIA Requirements Documentation for core principles and requirements for this specification.

7.2. Acknowledgments

The DID Alliance (DIDA) is an open industry association created to drive the development of a standardized, interoperable framework for decentralized identity services to ensure the authenticity of and establish trust in digital identities.

7.2.1. Contributors

7.2.2. Reviewers

Charlie Hart, Nicko Van Someren, Khaja Ahmed, Dean Saxe, Shrisha Radhakrishna, Sunpreet Arora, Kim Wagner, Joe Pennisi, Eve Maler, Phil Shoemaker, James Greaves, Jaechul Ryu, Hangbae Jang, Kumardas Karunakaran, Corey Segall, David Henstock

If a credit is missing from the credit list below, please log a ticket at GitHub to be recognized in future updates.

Index

Terms defined by this specification

References

Normative References

[ADIA-Corporate-Governance]
ADIA Corporate Governance. 5 January 2021. Editor's Draft. URL: https://adiassociation.github.io/ADIA-specification/ADIA-corporate-governance.html
[ADIA-Overview]
ADIA Overview. 5 January 2021. Editor's Draft. URL: https://www.adiassociation.org/spec/ADIA-overview.html
[ADIA-Protocol]
ADIA Protocol. 5 January 2021. Editor's Draft. URL: https://www.adiassociation.org/spec/ADIA-protocol.html
[ADIA-Specification-Governance]
ADIA Specification Governance. 5 January 2021. Editor's Draft. URL: https://adiassociation.github.io/ADIA-specification/ADIA-spec-governance.html
[DID-CORE]
Manu Sporny; et al. Decentralized Identifiers (DIDs) v1.0. 3 August 2021. PR. URL: https://www.w3.org/TR/did-core/
[DIDCOMM-MESSAGING-V1]
DIDComm Messaging. Accepted. URL: https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0005-didcomm/README.md
[FIPS-180-4]
FIPS PUB 180-4 Secure Hash Standard. URL: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
[ISO3166]
Codes for the representation of names of countries and their subdivisions — Part 1: Country code. August 2020. Published. URL: https://www.iso.org/standard/72482.html
[JSON]
ECMA-404 The JSON Data Interchange Format. October 2013. URL: https://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[RFC3339]
G. Klyne; C. Newman. Date and Time on the Internet: Timestamps. July 2002. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc3339
[RFC4122]
P. Leach; M. Mealling; R. Salz. A Universally Unique IDentifier (UUID) URN Namespace. July 2005. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc4122
[RFC4648]
S. Josefsson. The Base16, Base32, and Base64 Data Encodings. October 2006. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc4648
[RFC8032]
S. Josefsson; I. Liusvaara. Edwards-Curve Digital Signature Algorithm (EdDSA). January 2017. Informational. URL: https://www.rfc-editor.org/rfc/rfc8032
[RFC8152]
J. Schaad. CBOR Object Signing and Encryption (COSE). July 2017. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8152
[RFC8418]
R. Housley. Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS). August 2018. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8418
[RFC8785]
A. Rundgren; B. Jordan; S. Erdtman. JSON Canonicalization Scheme (JCS). June 2020. Informational. URL: https://www.rfc-editor.org/rfc/rfc8785
[SP800-63A]
P. Grassi; et al. NIST Special Publication 800-63A: Digital Identity Guidelines - Enrollment and Identity Proofing Requirements. June 2017. URL: https://doi.org/10.6028/NIST.SP.800-63a
[UAFProtocol]
R. Lindemann; et al. FIDO UAF Protocol Specification v1.2. Proposed Standard. URL: https://fidoalliance.org/specs/fido-uaf-v1.2-ps-20201020/fido-uaf-protocol-v1.2-ps-20201020.html
[VC-DATA-MODEL]
Manu Sporny; et al. Verifiable Credentials Data Model v1.1. 3 March 2022. REC. URL: https://www.w3.org/TR/vc-data-model/
[WebAuthn]
Dirk Balfanz; et al. Web Authentication: An API for accessing Public Key Credentials Level 1. March 2018. CR. URL: https://www.w3.org/TR/webauthn/