Verifier Universal Interface

Decentralized Identity (DeID) or "self-sovereign" identity (SSI), is a new paradigm proposed for managing digital identities. By relying on Decentralized identifiers (DIDs) and Verifiable Credentials (VC), a user or entity and their identity credentials are independent from any centralized registry, identity provider, or certificate authority.

On the Decentralized Identity model, the role associated to an entity receiving VCs for verification and processing purposes is defined as the Verifier. We will refer to Verifier component as the software component that implements the functionalities required by a Verifier.

The objective of a Verifier component is to support the Verifier to collect and verify VCs from a subject for the purpose of executing a transaction. It does so by:
  1. creating Presentation Requests (or Presentation Definition as defined in the DIF specfication for Presentation Exchange) that includes de number and type of VCs needed for the transaction
  2. sending the Presentation Request to the VC's holder
  3. receiving requested VCs wrapped in a Presentation, verifying that they match the number and type specified in the Presentation Request
  4. verifying the signature and any other proofs of the veracity of both the Presentation and its included VCs

This document proposes a set of APIs to be implemented by any Verifier component willing to interoperate in the DeID ecosystem. This set of APIs is hereafter referred as Verifier Universal Interface.

Despite its format, this document is not a draft work related to the W3C. This format is however extremely adequate to enable collaboration and contribution to the definition of standard interfaces in the DeID space.

Context

As different technology providers are building DeID solutions, it becomes a relevant matter to ensure interoperability between those solutions. In an inmature market with lack of atomized, interoperable components, many providers opt to build the entire DeID stack: components for holders, verifiers, issuers and a did-resolver that work as whole, but do not interoperate with other components.

In order to avoid vendor lock-in situations and guarantee an interoperable DeID layer for the Internet, the APIs exploited by Verifier components SHALL be standarized. This document aims to propose a set of universal API that provide sufficient capabilities for a Verifier component, while enabling integration with components of another DeID provider. It exploits existing work currently done at w3c-ccg, DIF, and other DeID communities.

Terminology

Decentralized Identifier (DID)
As defined in [[DID-CORE]].
DID document
As defined in [[DID-CORE]].
DID resolution
As defined in [[DID-RESOLUTION]].
DID resolver
As defined in [[DID-RESOLUTION]].
Verifier
As defined in [[VC-DATA-MODEL]].
Verifiable Credential (VC)
As defined in [[VC-DATA-MODEL]].
Verifiable Presentation (VP)
As defined in [[VC-DATA-MODEL]].
Schema Registry
See Section .
Issuer Registry
See Section .
Presentation Request (PR)
See Section .

Verifier operations

Any Verifier MUST perform the following operations:

  1. Request and receive specific information to holders in the form of Verifiable Credentials (presented in a Verifiable Presentation)
  2. Verify received VCs. This includes:
    1. Verify the proofs of every VC
    2. Verify the proof of the Presentation
    3. Verify that VCs received match VCs requested
Additionally, any Verifier SHALL perform the following operations:
  1. While verifying each VC:
    1. Verify the Issuer of the VC
      1. Its authority over the VC
      2. Its associated trust level
    2. Verify the status of the VC
    3. Verify and match the ownership of the VC and its Verifiable Presentation
    4. Verify that all VCs can be linked to the same holder
    5. Verify that the VC satisfies some established constraints
  2. Verify that the Verifiable Presentation has been sent from a secure wallet
  3. Authenticate the wallet owner
  4. Manage the consent on the purpose of use for each VC
  5. Ensure user non external traceability and ensure anonimity
  6. Manage selective disclosure of the information contained on the credentials

Assumptions

The are assorted perspectives and solutions for DeID models. This Verifier Open Protocol propose a set of APIs under some strict assumptions and conditions, justified for the sake of simplicity and conformance with current regulation.
DLT Agnosticity
DID methods may rely on different DLTs to store DID Documents, as well as other elements or documents necessary in a DeID ecosystem. As such, no solution that depends on a specific DLT shall be considered. DLTs MAY be exclusively used as a decentralized Public Key Infrastructure to verify cryptographic signatures of elements.
DLT as DKPI
While some technology providers may use DLTs to register assorted documents or information other than DIDs and associated public keys (e.g. credential status, issuance proofs, or issuer registries), DLTs MAY be exclusively used as a decentralized Public Key Infrastructure. As such the Verifier Open Protocol MUST allow the processing of information other than DIDs and DID Document components in alternative technologies.
Identity Governance
There SHALL be a party responsible for reviewing and defining which information can be attested by different Issuers. In order to comply with regulation, Issuers shall be known and registered along with their allowed Verifiable Credential schemas
There MUST be accessible registries to find available Issuers and Credential Schemas.
Monoclaim credentials
In order to ensure data minimization and allow selective disclosure, all VCs handled on both Presentation Requests and Verifiable Presentations MUST be monoclaim.
A monoclaim VC is a credential containing no more than the subject of the credential and a single claim. No credential can contain more than one claim. The format of that claim MAY be however freely defined.
Different claims strictly related among them, or belonging to a single conceptual Credential MAY be grouped into a Credential Group. For instance, Street Address, ZIP Code, City, and Country MAY be grouped into a Credential Group type PhysicalAddress. Alternatively, these attributes could also be considered as a as single claim wrapped in a monoclaim VC. However, this alternative would not allow for selective disclosure; that is, to share only the ZIP code without revealing the entire physical address.
This condition is established due to the lack of legal support (as of the date if this document) for Zero Knowledge Proof techniques to implement selective disclosure in multi-claim VCs.

Interfaces

In order to allow Verifier operations as decribed in the previous section, this document proposes a definition of the Interfaces between the Verifier and any other DeID component.

These interfaces MUST be independent from any framework or programming language. Interfaces shall be implemented with standard communication protocols through web services. Usage of REST is recommended.

A Verifier component SHALL make use of one or more of the following interfaces depending on the DeID component it wants to interact with:
                 +------------------------------------++------------------------------------++-----------------++-----------------+
                 |            Holder                  ||             Governance             ||  DID Resolver   ||     Issuer      |
                 +------------------------------------++------------------------------------++-----------------++-----------------+
                +------------------------------------------------------------------------------------------------------------------+ 
                |+-----------------++-----------------++-----------------++-----------------++-----------------++-----------------+|
                ||       API       ||       API       ||       API       ||       API       ||       API       ||      API        ||
                ||                 ||                 ||                 ||                 ||                 ||                 ||
                || Presentation    || Consent         || Schema Registry || Issuer Registry || DID Resolution  || Credential      ||
                || Exchange        || Management      || Query           || Query           ||                 || Status          ||
                ||                 ||                 ||                 ||                 ||                 || Query           ||
                ||                 ||                 ||                 ||                 ||                 ||                 ||
                ||                 ||                 ||                 ||                 ||                 ||                 ||
                ++-----------------++------------------------------------++-----------------++-----------------++-----------------++
                |                                                  Verifier Operations                                             |
                |+-----------------++-----------------++-----------------++-----------------++-----------------++-----------------+|
                |   1, 2.3, 3,      |     2.6, 2.7,    |       2.6, 7     |      2.2         |      2.1, 2.2,   |      2.3         |
                |    4, 6, 7        |       5, 6       |                  |                  |       2.4, 4     |                  |              
                |                                                                                                                  |
                +------------------------------------------------------------------------------------------------------------------+
            
Set of Open Interfaces for a Verifier Component and associated Verifier Operations they implement.

DID Resolution

Standard protocol and considerations for DID Resolution is being defined by a specific working group. See [DID-RESOLUTION] .

Credential Status

Standard protocol and considerations for querying the status of the credentials and managing their revocation is being defined by a specific working group. See [VC-STATUS-RL-2020] .

Registries

Registries managed by the Identity platform governance are needed to:

  1. Discover the credentials available on the Identity platform
  2. Manage the format of every credential
  3. Stablish the relation between different credentials, taken as attributes to build more complex credentials
  4. Define and restrict the entities enabled to assert and validate the information from the subjects
  5. Assign different levels of trust to the identity validation processes

Registries of Issuers and Credential Schemas MAY be separated and managed by different entities. Multiple registries of Issuers and/or Schemas MAY be queried by a Verifier.

Verifiers MAY make use of internal private registries to complement the public registries. Defining a protocol to merge different registries is outside the scope of this document.

Registries SHALL be publicly available and auditable. Persisting registries on DLTs is OPTIONAL but RECOMMENDED as good practice in order to maintain neutrality.

Registry Query

Registries MUST offer a web interface. REST protocol SHOULD be employed with HTTP Method GET and JSON formatting as default.

Registries SHOULD present a unique endpoint to retrieve different entities. The entity SHOULD be selected with either a path or a query parameter. For query parameters, the parameter name MUST be "entity".

Entity names MUST be:

                    
    GET https://registry.org/api/v1/ssiregistry/credentialTypes
                        GET https://registry.org/api/v1/ssiregistry/credentialGroups
                        GET https://registry.org/api/v1/ssiregistry/authority
                    
                        
    GET https://registry.org/api/v1/ssiregistry?entity=credentialTypes
                            GET https://registry.org/api/v1/ssiregistry?entity=credentialGroups
                            GET https://registry.org/api/v1/ssiregistry?entity=authority
                        

Authentication

Registries SHOULD be public.

However, for a better adaptability to business requirements, registries MAY be authenticated.

Authentication SHOULD be enforced following current web service standards: on HTTP/HTTPs interfaces, it should be handled with current standard authentication protocols, such as Basic Auth, Bearer tokens, OAuth2.0 or OpenId Connect.

Discovery

To be defined.

This section should be filled with discovery of registry endpoints for automatic configuration, as well as protocols to discover other registries.

Schema Registry

The Schema registry satisfies the needs of managing the credentials available in the platform, with their format and internal relations.

This definition proposal has tried to unify several credential Catalogs usages or efforts: Gataca Catalog, Jolocom andDIF's Credential Manifest

Data Model

Credential Types

Credential types represent all the types of the different available monoclaim verifiable credentials; each of the types representing each an unique attribute of any credential.

                        Credential types represent minimal information: email, first name, last name...
                    

The usage of monoclaim credentials is required to ensure both:

Id
Credential Types MUST have an Id mapping to the most restrictive type of the verifiable credential. The id MUST be unique on its registry.
Name
Credential Types MUST have a short description to represent them on a human-readable way. The name property MUST contain a map with different descriptions depending on the Locale code. The name MUST NOT be empty and have at least a default value.
Group List
Credential Types MUST refer the list of Credential groups where they can be assessed. The list MUST contain 1 or more groups. The same attribute MAY be present in more than one group, while its schema MUST be fix on all those groups.
                                An attribute credential of type first name could be found in multiple more complex credentials: passports, driver licenses, academic certificates... 
                            
Schema URI
Credential Types SHALL provide a public URL to retrieve their schema on a machine-readable way. The schema MUST provide the format enforced by the credential,
Schema
Credential Types MAY have their schema defined. Either the Schema or the Schema URI properties MUST be defined to validate the credential formats.
Description
Credential Types MAY have a human readable description to allow external users to understand the information contained on the credential and how to use it. The description MAY provide additional information to the description present on the Credential schema.
                        
    {
                                "groupList": [ "email"],
                                "id": "emailCredential",
                                "name": {
                                    "en": "Email"
                                },
                                "schema": "{\"title\":\"JSON Schema for monoclaim verifiable credentials of type emailCredential\",\"required\":[\"credentialSubject\",\"id\",\"issuanceDate\",\"issuer\",\"proof\",\"type\"],\"properties\":{\"credentialSubject\":{\"title\":\"Claims established about the subject defined by his DID.\",\"required\":[\"id\"],\"properties\":{\"id\":{\"title\":\"DID identifier of the subject about whom the claims have been verified\",\"default\":\"\",\"pattern\":\"^did:gatc:[A-Za-z0-9]{32}$\",\"examples\":[\"did:gatc:OWU3ZGRhOGJmYTY1ZjNlODBhZmY4MDgx\"],\"$id\":\"#/properties/credentialSubject/properties/id\",\"type\":\"string\"},\"email\":{\"title\":\"Email address owned by the subject\",\"default\":\"\",\"format\":\"email\",\"examples\":[\"example@example.com\"],\"$id\":\"#/properties/credentialSubject/properties/email\",\"type\":\"string\"}},\"$id\":\"#/properties/credentialSubject\",\"type\":\"object\"},\"credentialStatus\":{\"title\":\"Current status resource of the credential\",\"required\":[\"id\",\"type\"],\"properties\":{\"id\":{\"title\":\"Unique Identifier of the Status Information\",\"default\":\"\",\"pattern\":\"^did:gatc:[A-Za-z0-9]{32}$\",\"examples\":[\"did:gatc:OWU3ZGRhOGJmYTY1ZjNlODBhZmY4MDgx\"],\"$id\":\"#/properties/credentialSubject/properties/id\",\"type\":\"string\"},\"type\":{\"title\":\"Status presentation standard\",\"default\":\"CredentialStatusList2017\",\"enum\":[\"CredentialStatusList2017\"],\"examples\":[\"did:gatc:OWU3ZGRhOGJmYTY1ZjNlODBhZmY4MDgx\"],\"$id\":\"#/properties/credentialSubject/properties/id\",\"type\":\"string\"}},\"$id\":\"#/properties/credentialStatus\",\"type\":\"object\"},\"id\":{\"title\":\"Gataca Verifiable Credential Unique Resource Identifier\",\"default\":\"\",\"pattern\":\"^cred:gatc:[A-Za-z0-9]{32}$\",\"examples\":[\"cred:gatc:MWJmNDk2M2ZlODgwYzIwZTkyZWFjMjY1\"],\"$id\":\"#/properties/id\",\"type\":\"string\"},\"issuanceDate\":{\"title\":\"Credential first issuance date\",\"default\":\"\",\"format\":\"date-time\",\"examples\":[\"2020-05-05T13:45:54Z\"],\"$id\":\"#/properties/issuanceDate\",\"type\":\"string\"},\"issuer\":{\"title\":\"DID Identifier of the first issuer that generated this credential\",\"default\":\"\",\"pattern\":\"^did:gatc:[A-Za-z0-9]{32}$\",\"examples\":[\"did:gatc:acYseLtTEVeqF8oBhJEejbCVHJ8auVupaRuo6gw4hmXjcc77uCKqyM3imEJH\"],\"$id\":\"#/properties/issuer\",\"type\":\"string\"},\"proof\":{\"title\":\"Array of proofs from different DIDs attesting this claim\",\"items\":{\"title\":\"Verifiable Data- Proof\",\"required\":[\"created\",\"creator\",\"proofPurpose\",\"proofValue\",\"type\"],\"properties\":{\"created\":{\"title\":\"Proof creation date\",\"default\":\"\",\"format\":\"date-time\",\"examples\":[\"2020-05-05T13:45:55Z\"],\"$id\":\"#/properties/proof/items/properties/created\",\"type\":\"string\"},\"creator\":{\"title\":\"Proof Signer Key\",\"default\":\"\",\"pattern\":\"^did:gatc:[A-Za-z0-9]{32}\\\\#(.*)$\",\"examples\":[\"did:gatc:acYseLtTEVeqF8oBhJEejbCVHJ8auVupaRuo6gw4hmXjcc77uCKqyM3imEJH#keys-1\"],\"$id\":\"#/properties/proof/items/properties/creator\",\"type\":\"string\"},\"proofPurpose\":{\"title\":\"Purpose enforced by the proof\",\"default\":\"assertionMethod\",\"enum\":[\"authentication\",\"assertionMethod\",\"keyAgreement\",\"contractAgreement\",\"capabilityInvocation\",\"capabilityDelegation\"],\"examples\":[\"authentication\"],\"$id\":\"#/properties/proof/items/properties/proofPurpose\",\"type\":\"string\"},\"proofValue\":{\"title\":\"Data Signature\",\"default\":\"\",\"pattern\":\"^(.*)$\",\"examples\":[\"SuDU_pRxRud6x-LDpuiSwv0bT9tW41eJR7R9SY4SxOm5jkbnRELXxqd5BqxyRp8d1DIKHgjuwGfAI9ceqDN1DQ\"],\"$id\":\"#/properties/proof/items/properties/proofValue\",\"type\":\"string\"},\"type\":{\"title\":\"Cryptographic signing protocol\",\"default\":\"Ed25519Signature2018\",\"enum\":[\"Ed25519Signature2018\",\"RsaSignature2018\"],\"examples\":[\"Ed25519Signature2018\"],\"$id\":\"#/properties/proof/items/properties/type\",\"type\":\"string\"}},\"$id\":\"#/properties/proof/items\",\"type\":\"object\"},\"$id\":\"#/properties/proof\",\"type\":\"array\"},\"type\":{\"title\":\"Credential Types defining the schemas this credential enforces\",\"items\":{\"title\":\"Credential Type description\",\"default\":\"\",\"enum\":[\"VerifiableCredential\",\"emailCredential\"],\"examples\":[\"VerifiableCredential\"],\"$id\":\"#/properties/type/items\",\"type\":\"string\"},\"$id\":\"#/properties/type\",\"type\":\"array\"}},\"$id\":\"https://gataca.io/verifiableCredentialSchema.json#\",\"type\":\"object\",\"definitions\":{},\"$schema\":\"http://json-schema.org/draft-07/schema#\"}"
                            }
                        
                        
    {
                                "groupList": [ "email"],
                                "id": "emailCredential",
                                "name": {
                                    "en": "Email",
                                    "es": "Email",
                                    "fr": "Email"
                                },
                                "schemaUri": "https://schema.org/EmailCredential",
                                "description": "This credential contains a verified email address from the user."
                            }
                        

Credential Groups

During an unique process of asserting the Subject's identity it MAY be possible to assert several of the attributes of his identity. Thus, as multiple claims can be stablished from a single process, the monoclaim Verifiable Credentials MUST be grouped into more complex structures, defined as Credential Groups. Credential Groups represent a set of monoclaim credentials bound together in order to build a more complex credential. All those credentials MUST be considered as belonging to the same credential, and their lifecycle managed uniquely.

Credentials should be presented however individually. To understand how credentials in groups must be used on presentations, refer to the following section

                        Credentials Groups represent complex credentials with multiple claims: drivers license, passport, academic certificate...
                    
                        Credentials Groups can represent also a complex credential with a single claim: email, phone number...
                    
Id
Credential Groups MUST have an unique identifier on the registry. The identifier SHOULD represent an unique process of identity-assertion, generating a complex multi-claim credential, from which one or more attributes of a subject identity can be extracted.
Name
Credential Groups MUST have a short description to represent them on a human-readable way, as a title of the credential. The name property MUST contain a map with different descriptions depending on the Locale code. The name MUST NOT be empty and have at least a default value.
Display
Credential groups represent complex credentials, human-readable and understandable for users. In order to allow customization or representation, they MUST contain information about how to represent them.
Main Claim
The main claim MUST represent the Credential Type most representative of the whole credential group to allow the presentation of its value to the user as a title.
                                        For a academic certificate credential, the academic degree obtained could be the main claim. 
                                    
Secondary Claim
The secondary claim MAY represent another Credential Type very representative of the credential group, to allow the presentation of its value to the user as a subtitle.
                                        For a academic certificate credential, the academic institution could be a secondary claim. 
                                    
Logo
The logo property MAY allow identifying a credential with a fixed logo. The logo can be defined by its URI, its content base64 codified or its svg definition.
URI
Base64
Svg
Background
The background property is OPTIONAL. It MAY be used to enforce a standard representation of the credential on different Wallets and User Agents.
Color
URI
Base64
Svg
Text
The text property is OPTIONAL. It MAY be used to define the presentation format of the text describing the credential.
Color
Font Family
Description
Credential Types MAY have a human readable description to allow external users to understand the information contained on the credential and how to use it. The description MAY provide additional information to the description present on the Credential schema.
                        
    {
                                "id": "university",
                                "name": {
                                    "en": "University Qualification",
                                    "es": "Título Universitario"
                                },
                                "description": "This credential group asserts the obtention of an academic degree by a valid academical institution.",
                                "display":{
                                    "mainClaim": "qualificationCredential",
                                    "secondaryClaim": "academicInstitutionCredential",
                                    "logo":{
                                        "uri":"https://www.svgrepo.com/show/293955/university.svg"
                                    },
                                    "background":{
                                        "color":"#1025a0"
                                    },
                                    "text":{
                                        "color":"#ffffff"
                                    }
                                }
                            }
                        

Issuer Registry

The issuer registry MUST contain all the different institutions that have been attested as valid verifiers of subject's identities.

There doesn't seem to be much standarization effort on defining different issuers.

Trust levels

Governance SHOULD assign different trust levels to the entity asserting the validity of the subject credentials.

Three different trust levels have been defined:

Level Indication Meaning
0 Self-attested The credential is asserted by the subject self. No external entity has validated the data.
1 Validated The credential is validated by an external entity which has been deemed able to validate that type of credential. The entity is not the issuer nor of the source of the data verified.
2 Issued The credential is validated by the same entity which is the owner or the source of the data verified.
                For a credential of type phone:
                    * Level 0: The subject could assert his phone number
                    * Level 1: A validator could verify the possesion of the phone using an OTP.
                    * Level 2: His phone company could assert the possesion of the phone number associated.
            

eIDas assigns 4 different levels of trust to the data. This model offers a simpler and different approach, regarding the entity validating the data; nor the validation process itself.

A same entity could have different Trust levels on the assertion of different credentials

                A bank entity could be:
                    * Level 1 validator of national documents
                    * Level 2 validator of IBANs of their bank
            

The trust level of a credential process should apply to credential groups, as the process of asserting identity claims usually applies to complex credentials with more than one claim.

Data Model

Authority

Id
Authorities MUST be represented by their unique DID.
Name
Authorities MUST have a short description to represent them on a human-readable way as a title. The name property MUST contain a map with different descriptions depending on the Locale code. The name MUST NOT be empty and have at least a default value.
Display
Authorities MAY contain additional display information to provide compliance with their digital image guidelines.
Logo
The logo property MAY allow identifying a credential with a fixed logo. The logo can be defined by its URI, its content base64 codified or its svg definition.
URI
Base64
Svg
Background
The background property is OPTIONAL. It MAY be used to enforce a standard representation of the credential on different Wallets and User Agents.
Color
URI
Base64
Svg
Text
The text property is OPTIONAL. It MAY be used to define the presentation format of the text describing the credential.
Color
Font Family
Credential List
Every authority MUST have a list of the different groups of credentials whose claims it can validate.
Group
Id of the Credential Group to validate
Trust Level
Designated trust level for that authority to that group. The trust level for any authority MUST be either 1 or 2.
                
    {
                        "id": "did:gatc:47bad539a8371e57ebb6370e6ac93bc2dddfa2f2f8a92c632de1e88ce166601f",
                        "name": {
                            "en": "Issuer Demo",
                            "es": "Emisor de prueba"
                        },
                        "display":{
                            "logo":{
                                "uri":"https://www.svgrepo.com/show/293955/university.svg"
                            },
                            "background":{
                                "color":"#1025a0"
                            },
                            "text":{
                                "color":"#ffffff"
                            }
                        },
                        "credentialList":[
                            { 
                                "group": "phone",
                                "trustLevel": 1
                            },
                            { 
                                "group": "email",
                                "trustLevel": 1
                            }
                        ]
                    }
                

Presentation Exchange

The presentation exchange is the protocol of communication between the Verifier and the Holder to retrieve Verifiable Credentials.

The presentation exchange consists on a two step process:

  1. The Holder retrieves a Presentation Request from the verifier.
  2. The Holder provides a Presentation Response, containing one or more verifiable presentations to the verifier.

Obtaining the Presentation Request

A Presentation Exchange takes place when a Service Provider, connected to a Verifier, needs to retrieve Verifiable Credentials from an end user. The user subject MAY store his credentials on a wallet Holder, either on the same or a different User-Agent and device than the Service Provider.

To access the Holder on any device, the Verifier MUST offer the user a deep link to retrieve the verifiable presentation.

DeepLink

The deep link MUST use an unique protocol definition: did://. Wallets on different user-agents MAY register to listen to that protocol. The protocol MUST NOT be the same as other existing protocols, even authentication protocols such as openid://, as presentation exchanges cover several use cases apart from authentication.

Deep Link format

did://presentation-exchange?uri=""&jwt=""

For presentation exchanges, the deep link should have the following properties:
Protocol
Permanent: did://
Action
Permanent: presentation-exchange
Parameters. Only one of the two options is required
uri
OPTIONAL: Base64URL encoding of the URI of the resource to retrieve the presentation request
jwt
OPTIONAL: JWT containing the presentation request on JWT format
                did://presentation-exchange?uri=aHR0cHM6Ly9jb25uZWN0LmdhdGFjYS5pbzo5MDkwL2FwaS92MS9zZXNzaW9ucy9Ea3N2QTB6bzFDVDR2SjNqbEZKcGMxRjFxejI1OEd1dg
            

Consider delegating services to allow static deep links

The format of this deep link is for the moment a suggestion. The definition of the deep link protocol may be outside the scope of this document.

In order to obtain the presentation request, the Verifier should detect the device of the subject compared to the expected Holder and offer two different behaviours:

Other technologies apart from QRs could be used to connect different devices: Bluetooth, Zigbee, NFC technologies... QRs have been chosen as a standard for simplicity and technical availability on the current user technical capacities. The same process of sharing just the generated Deep Link should work independently on the channel chose.

Deep Link obtention depending on device

Displaying JWT with Deep Links on QRs might result on very big QRs, resulting on qrs difficult to ready or display and lowering user experience. Therefore the use of URIs is RECOMMENDED when displaying QRs.

Model

Presentation Request

The presentation request is a JSON-LD Document to provide a fine-grain definition of which claims are requested by the Verifier, with a strict statement of the purpose for the usage of each piece of information. Claims are mapped to the available Credential Types on the catalog, representing all the possible available attributes.

There are other presentation exchange efforts. See . Those efforts are not considering the assumptions stablished on this document. This proposal is oriented to present a better interface based those assumptions.

Id
Presentation Requests MUST be uniquely identified. The identifier MUST be used on the Presentation Response as proof of correspondence to the previous request.
Nonce
Presentation Requests MUST contain a unique nonce to avoid replay attacks.
Callback
Verifier domain to forward the corresponding Presentation Response
Requested
List of Credential Requests stablishing the Credential Types from the catalog needed by the Verifier on the exchange.
Proof

Presentation Requests MUST contain a proof (see [[LD-PROOFS]]) to provide mutual authentication. Proofs must be signed with the Verifier's DID Keys.

Proof Purpose MUST be assertionMethod.

Proofs MUST contain a challenge to avoid replay attacks.

Auth

List of Security Mechanisms to be enforced by the Wallet. Those mechanisms SHALL provide additional security verifications, such as wallet application authentication or wallet owner.

All items on the list MUST be enforced - Logical Conjunction - whereas only one of the accepted mechanisms stablished for a single item MUST be enforced - Logical disjunction-.

                
                {
                    "auth": [{
                        "accepted": ["any"],
                        "type": "WalletAuth"
                    }, {
                        "accepted": ["Biometric", "Silent"],
                        "type": "AuthNFactor"
                    }],
                    "callback": "https://connect.dev.gataca.io:9090",
                    "id": "d2b2e10c-d894-4614-a003-630958ee4a02",
                    "nonce": "750655b9-dca0-48a6-8508-ad3f947c9d34",
                    "proof": [{
                        "challenge": "28BuRkhd4Z9FbXfL4cHTBUk1iL75VtJa",
                        "created": "2020-11-06T12:48:51Z",
                        "creator": "did:gatc:22bhyz2xdJbKV2ZLUpedzqXbSoh9Gofw#keys-1",
                        "domain": "gatacaid.com",
                        "proofPurpose": "assertionMethod",
                        "proofValue": "62Q4ZWDlVxyosDINKBvpdhsr_bGOMdpqwtnIHMtkYMv6ViGNtFUAHRN4giyV95SGg93wp9-wDNaK9bcSXLywDQ",
                        "type": "Ed25519Signature2018"
                    }],
                    "requested": [{
                        "mandatory": true,
                        "purpose": "authentication",
                        "trustLevel": 2,
                        "type": "studentIdCredential"
                    }, {
                        "mandatory": false,
                        "purpose": "application",
                        "trustLevel": 0,
                        "type": "lastNameCredential"
                    }, {
                        "mandatory": false,
                        "purpose": "application",
                        "trustLevel": 0,
                        "type": "firstNameCredential"
                    }, {
                        "mandatory": true,
                        "purpose": "authentication",
                        "trustLevel": 2,
                        "type": "academicInstitutionCredential"
                    }]
                }
                

Credential Request

Credential Requests define each of the claims needed by the verifier.

Type
Credential Type, as defined in the , of each of the specific claims requested. It MUST be stated for selection on the client side. The schema of the verifiable credential received will match the stated type.
Trust Level
The minimal Trust Level of the verifier of the credential, as defined in the , MUST be stated to restrict selection on the Wallet application.
Mandatory
Credentials MAY be optionally requested to improve user experience or business applications. Holders will be able to decide whether including non-mandatory credentials on their presentation responses.

Default: false

Purpose
Purpose of the credential that MUST be stated for communication with the User. See section
Constraints
The selection of the credential MAY be restricted on the client side. See section
                    
    {
                            "mandatory": true,
                            "purpose": "authentication",
                            "trustLevel": 2,
                            "type": "studentIdCredential"
                            "constraints":[
                                {"eq":{"issuer", "did:gatc:323agw4825u56539d1f"}}
                            ]
                        }
                    

Credential Purposes

The credential purpose MUST be adequate to the purpose stated and accepted on the Consent document.

Credential purposes SHALL provide support for GDPR and other privacy regulations. Vocabulary SHOULD be in line with Data Privacy Vocabulary. The list of all accounted purposes SHOULD be checked to match this document.

The purpose of the credential must be graduated, from the most restricted to the least restricted, depending on the necessity to provide service. Consenting to a higher purpose SHOULD automatically accept consent to more restrictive purposes.

The existing purposes are:

  1. Identify verification
  2. Fraud detection and prevention
  3. Access control
  4. Service Provision
  5. Service Optimization
  6. Service Personalisation
  7. Marketing
  8. Commercial Interests
  9. Research & Development

Purposes MUST always be defined as the most restrictive purpose matching the intended use of the corresponding claim.

Constraints

Constraints MAY be used to restrict the selection of the credential to match verifiers needs. They are intended to improve processes where multiple claims matching the requirements would be available on the Holder Wallet.

Holders MUST be able to handle cases where no credentials matching the specified constraints -including type and trust level are available. Considerations or guidelines on User Experience on Wallets are outside the scope of this document.

Constraints MAY be specified using the following format:

{ "operator1":{"key1":"value2"}, ..., "operatorN":{"keyN":"valueN"}}

On a list of constraints, they would be applied with a Disjuntive Logic -Logical OR-. Operators on the same contraint are applied with a Conjunctive Logic -Logical AND-.

Keys MAY be specified with dot-object notation, refering to any existing property on a Verifiable Credential.

Operators
One of four possible values:
  • eq
  • ne
  • ge
  • le

                        Obtaining credentials issued after 2018 from two possible issuers:
                        
        {
                                "mandatory": true,
                                "purpose": "authentication",
                                "trustLevel": 2,
                                "type": "studentIdCredential"
                                "constraints":"constraints":[
                                    {"eq":{"issuer", "did:gatc:WTKl4E1TdAr0pOiJDvL4aP7slFV7K1aH"}, "ge":{"issuanceDate","2018-01-01T00:00:00"}},
                                    {"eq":{"issuer", "did:gatc:loDNgbQXa4naoh4Gqr28nHYeObyfvZS8"}, "ge":{"issuanceDate","2018-01-01T00:00:00"}},
                                ]
                            }
                        

Legal validation and compliance SHALL be enforced by the especification of the proof type to legal compliance types. For instance, eIDAS validation type

                    
        {
                            "mandatory": true,
                            "purpose": "authentication",
                            "trustLevel": 2,
                            "type": "studentIdCredential"
                            "constraints":[
                                {"=":{"proof.type", "EidasValidatedSignature2020"}}
                            ]
                        }
                    

Security Mechanisms

Security Mechanisms are additional authentication factors designed to provide additional guarantees on the source of the credentials.

There are two kinds of possible Security Mechanisms to be enforced by the Holder Wallet: Wallet Authentication and AuthNFactor Credentials

Other security mechanisms might be defined on future revisions of the document.

Wallet Authentication

Wallet Authentication is required to ensure that the wallet holding the credentials is actually a secure environment, by identifying uniquely the wallet on which the Presentation Response has been generated.

Auditing Credential Wallets from different providers SHOULD be required to ensure an acceptable level of integrity on managing the data.

Correct data models and cryptographic schemes SHOULD NOT be easily trusted, unless the source is proven.

Wallet Authentication relies on assigning a DID to the wallet application. The corresponding private key to the DID MUST be securely embedded inside the Wallet Application.

If a Presentation Request requires a Wallet Authentication Security Mechanism, then on presentation response, a WalletAuthentication object MUST be present with the two properties:

DID
DID corresponding to the wallet embedded key.
Proof
Presentation request nonce signed with the Wallet DID Private Key.

The listing of all possible secure Wallets DIDs, along with its discovery, is outside the scope of this document, at least on its first version.

Defying characteristics and security requirements on Wallets or on client keys management is outside the scope of this document. It is however RECOMMENDED that the Wallet DID Key is composed between two halves -client side & server side- with obfuscation and sandbox detection techniques to avoid the retrieval of the real private key.

AuthNFactor Credentials

AuthNFactor Credentials are a specific subtype of Verifiable Credentials that MAY be used to authenticate the Subject and provide serverside proofing of that authentication.

AuthNFactor Credentials are credentials to wrap a Cryptographic KeyPair:

  • The Public part of the key is stated as the claim of the credential.
  • The Private part of the key is stored on the Wallet's secure storage. To retrieve the private part from the wallet, the Subject MUST perform an authentication process, such as receiving an OTP or inputing his biometry.

AuthNFactor Credentials are proposed as an adaptation of the FIDO standard to the Verifiable Credentials model. There are other interesting contributions on this line, such as DIF's Horcrux.

AuthNFactor Credentials consist on a single claim with the following properties:

Id
Anywise DID of the Subject
Public Key
Public part of the cryptographic keypair associated to this AuthNFactor Credential
Receiver
A receiver information MAY be stated on the credential, to link the AuthNFactor with other Credentials from the subject.
                                    * A biometric AuthNFactor Credential MAY be linked to the device containing the biometric capacities by stating the deviceId on the receiver property.
                                    * An email AuthNFactor Credential MAY be linked to the email account receiving the OTP by stating the account on the receiver property.
                                

AuthNFactor Credentials MAY be of one of the following types

email
Subject MUST perform a second factor authentication via OTP received on the email.
phone
Subject MUST perform a second factor authentication via OTP received on his phone.
silent
Subject MUST conform his identity by having the wallet application currently open on his device, without providing any further interaction.
biometric
Subject MUST perform a biometric authentication as a second factor.

AuthNFactor Credentials MUST be issued by the same trusted provider in charge of governing the Wallet.

                        
                            {
                                "credentialSubject": {
                                    "id": "did:gatc:YjcwNDgzMWU1ODA0ZmU2NDU0MjU0YzNl",
                                    "publicKey": "BqBaKkzcbwmFq9m89jaGEXRur8XzWssZcns83AV2iQfG",
                                    "receiver": "216a4aeed3536a68"
                                },
                                "id": "cred:gatc:MDAyNjA2MTdiNWM0ZWMwNzA1ZjczOTNj",
                                "issuanceDate": "2020-11-06T08:32:12Z",
                                "issuer": "did:gatc:acYseLtTEVeqF8oBhJEejbCVHJ8auVupaRuo6gw4hmXjcc77uCKqyM3imEJH",
                                "proof": [{
                                    "created": "2020-11-06T08:32:13Z",
                                    "creator": "did:gatc:acYseLtTEVeqF8oBhJEejbCVHJ8auVupaRuo6gw4hmXjcc77uCKqyM3imEJH#keys-1",
                                    "proofPurpose": "authentication",
                                    "proofValue": "BnE9Hjs4yBMCoSRPCfc-s141E-sD0847RHSFsSJ5lGeeC15vAlIjAxaLXN_N7FnKMjIrx-yiIkhLKvTn4XmYCQ",
                                    "type": "Ed25519Signature2018"
                                }],
                                "type": ["VerifiableCredential", "biometricAuthNFactorCredential"]
                            }
                        

If a Presentation Request requires a Wallet Authentication Security Mechanism, then on presentation response, a AuthNFactorCredentials object MUST be present containing a Verifiable Presentation:

The AuthNFactorCredentials presentation MUST be signed by each the Private Keys of each the AuthNFactor Credentials selected.

Each presentation proof MUST contain the nonce of the corresponding presentation request as a challenge.

Each of the proof creators MUST refer to the id of the AuthNFactor Credential used for proofing.

Specific AuthNfactor credentials shall be defined on different wallets and DeID technology stacks. The listing of all the possible AuthNFactor types, as well as its management and discovery, is outside the scope of this document.

Presentation Response

A Presentation Response is a document created by the Holder to satisfy a Presentation Request.

It is composed of Verifiable Presentations to allow the successive data validation from the Verifier.

Id
The Presentation Response Id MUST match the Id of the Presentation Request to be satisfied.
Credentials

Verifiable Presentation containing the selection of Verifiable Credentials satisfying the requirements stablished by the Presentation Request.

The Presentation MUST be signed by a PairWise DID.

The Subject of all the Credentials existing on the presentation SHOULD be the same.

The presentation proof MUST contain the nonce of the associated presentation request as a challenge.

Non-mandatory credentials MAY not be present on the Verifiable Presentation.

The process of building a digital identity should be implemented by linking a growing number of proved claims to a single identifier. However, it is possible for a single subject to possess multiple DIDs -for instance on multiple DeID platforms-. Being able to trace and assert the relation of various DIDs to a single subject is an authentication need outside the scope of this document.

Security Mechanisms

Proof of enforcement of the requested security mechanisms. There are two possible properties:

Wallet Auth
Wallet Identifier and its corresponding proof, as the nonce signed with the corresponding key
AuthNFactor Credentials
Verifiable Presentation with the AuthNFactor Credentials enforced, proofed by each of the related keys.
            
    {
                    "id": "d2b2e10c-d894-4614-a003-630958ee4a02",
                    "securityMechanisms": {
                        "walletAuth": {
                            "id":"did:gatc:CehhauO4AL2KSkW40PtAMS57XteDYCFv",
                            "proof":"ZX9CVNQhWpFpiVwuxNWvGoj_iNRWErrv3rpKhXbayBFgFmJVFA6-h1Bx8bb4bl7Z9reJ9BjXchptTzh4PLf3"
                        },
                        "authNFactorCredentials": {
                            "@context": ["https://www.w3.org/2018/credentials/v1"],
                            "proof": [{
                                "challenge": "750655b9-dca0-48a6-8508-ad3f947c9d34",
                                "created": "2020-11-06T12:48:53Z",
                                "creator": "cred:gatc:MDAyNjA2MTdiNWM0ZWMwNzA1ZjczOTNj",
                                "proofPurpose": "authentication",
                                "proofValue": "FgFmJVFA6-38np0wG7YxYPgN8zofB_ZX9CVNQhWpFpiVwuxNWvGoj_R3V9PGtJiNRWErrv3rpKhXbayBxzxFCw",
                                "type": "Ed25519Signature2018"
                            }],
                            "type": ["VerifiablePresentation", "GatacaCredentialPresentation"],
                            "verifiableCredential": [{
                                "credentialSubject": {
                                    "id": "did:gatc:YjcwNDgzMWU1ODA0ZmU2NDU0MjU0YzNl",
                                    "publicKey": "BqBaKkzcbwmFq9m89jaGEXRur8XzWssZcns83AV2iQfG",
                                    "receiver": "216a4aeed3536a68"
                                },
                                "id": "cred:gatc:MDAyNjA2MTdiNWM0ZWMwNzA1ZjczOTNj",
                                "issuanceDate": "2020-11-06T08:32:12Z",
                                "issuer": "did:gatc:acYseLtTEVeqF8oBhJEejbCVHJ8auVupaRuo6gw4hmXjcc77uCKqyM3imEJH",
                                "proof": [{
                                    "created": "2020-11-06T08:32:13Z",
                                    "creator": "did:gatc:acYseLtTEVeqF8oBhJEejbCVHJ8auVupaRuo6gw4hmXjcc77uCKqyM3imEJH#keys-1",
                                    "proofPurpose": "authentication",
                                    "proofValue": "BnE9Hjs4yBMCoSRPCfc-s141E-sD0847RHSFsSJ5lGeeC15vAlIjAxaLXN_N7FnKMjIrx-yiIkhLKvTn4XmYCQ",
                                    "type": "Ed25519Signature2018"
                                }],
                                "type": ["VerifiableCredential", "silentAuthNFactorCredential"]
                            }]
                        }
                    },
                    "credentials": {
                        "@context": ["https://www.w3.org/2018/credentials/v1"],
                        "proof": [{
                            "challenge": "750655b9-dca0-48a6-8508-ad3f947c9d34",
                            "created": "2020-11-06T12:48:57Z",
                            "creator": "did:gatc:OTk5ZDIxNjEzYjBlNWViN2VlNjRhNTJi#keys-1",
                            "proofPurpose": "authentication",
                            "proofValue": "WNYVmiQe8qYqt3z3YNi33E-iNTmxHtLozsZUA3G4YfYTc6mJd70evnoOIBIxY1MMA62q9SjQ6egws7zd5R-UAg",
                            "type": "Ed25519Signature2018"
                        }],
                        "type": ["VerifiablePresentation", "GatacaCredentialPresentation"],
                        "verifiableCredential": [{
                                "credentialStatus": {
                                    "id": "https://certify.dev.gataca.io:9090/api/v1/group/student/status",
                                    "type": "CredentialStatusList2017"
                                },
                                "credentialSubject": {
                                    "id": "did:gatc:YjcwNDgzMWU1ODA0ZmU2NDU0MjU0YzNl",
                                    "studentId": "johnsmith10"
                                },
                                "id": "cred:gatc:tqn2onxicmlezcmollcdkmjgyrj53b1x1086",
                                "issuanceDate": "2020-11-06T11:57:32Z",
                                "issuer": "did:gatc:272NzLZEDL67Y2riuAkya9gnXgAicZxH",
                                "proof": [{
                                    "created": "2020-11-06T11:57:32Z",
                                    "creator": "did:gatc:272NzLZEDL67Y2riuAkya9gnXgAicZxH#keys-1",
                                    "proofPurpose": "authentication",
                                    "proofValue": "1U66hjpO-Ep78fR60ArTxIKjqdnpsSKee1AjQOxtsCmBdfzQbAniBsYFNmWSuexgaxEHYZpXTeTBZpfdxdUZBA",
                                    "type": "Ed25519Signature2018"
                                }],
                                "type": ["VerifiableCredential", "studentIdCredential"]
                                }, {
                                "credentialStatus": {
                                    "id": "https://certify.dev.gataca.io:9090/api/v1/group/student/status",
                                    "type": "CredentialStatusList2017"
                                },
                                "credentialSubject": {
                                    "id": "did:gatc:YjcwNDgzMWU1ODA0ZmU2NDU0MjU0YzNl",
                                    "lastname": "SMITH"
                                },
                                "id": "cred:gatc:4npxte79gk55zis44339zast75dq94mjqmyk",
                                "issuanceDate": "2020-11-06T11:57:32Z",
                                "issuer": "did:gatc:272NzLZEDL67Y2riuAkya9gnXgAicZxH",
                                "proof": [{
                                    "created": "2020-11-06T11:57:32Z",
                                    "creator": "did:gatc:272NzLZEDL67Y2riuAkya9gnXgAicZxH#keys-1",
                                    "proofPurpose": "authentication",
                                    "proofValue": "foHciBH0tBZmIrS6SbI2t3vF6iqvWJFdtfRp6hnsIEGcPqCu27WXLYYNqgMmn2lJaj9nJG91Km-_low_TLf7DQ",
                                    "type": "Ed25519Signature2018"
                                }],
                                "type": ["VerifiableCredential", "lastNameCredential"]
                            }, {
                                "credentialStatus": {
                                    "id": "https://certify.dev.gataca.io:9090/api/v1/group/student/status",
                                    "type": "CredentialStatusList2017"
                                },
                                "credentialSubject": {
                                    "firstname": "JOHN",
                                    "id": "did:gatc:YjcwNDgzMWU1ODA0ZmU2NDU0MjU0YzNl"
                                },
                                "id": "cred:gatc:0w334gdrx87duqanp1eymfzlcyh22g0ox32z",
                                "issuanceDate": "2020-11-06T11:57:32Z",
                                "issuer": "did:gatc:272NzLZEDL67Y2riuAkya9gnXgAicZxH",
                                "proof": [{
                                    "created": "2020-11-06T11:57:32Z",
                                    "creator": "did:gatc:272NzLZEDL67Y2riuAkya9gnXgAicZxH#keys-1",
                                    "proofPurpose": "authentication",
                                    "proofValue": "ImRTvgGGbJt-0achi8jGuBtFnulp-KTi7Sp_7q4uSR-QZiEJUeQ7ugmUePCqCI6HMw5LiyMa7zMPB2JFvP35DA",
                                    "type": "Ed25519Signature2018"
                                }],
                                "type": ["VerifiableCredential", "firstNameCredential"]
                            }, {
                                "credentialStatus": {
                                    "id": "https://certify.dev.gataca.io:9090/api/v1/group/student/status",
                                    "type": "CredentialStatusList2017"
                                },
                                "credentialSubject": {
                                    "academicInstitution": "Awesome Technical University",
                                    "id": "did:gatc:YjcwNDgzMWU1ODA0ZmU2NDU0MjU0YzNl"
                                },
                                "id": "cred:gatc:a00loy0pcfkdiq6tx9sburq5a2jl6r1z2icc",
                                "issuanceDate": "2020-11-06T11:57:32Z",
                                "issuer": "did:gatc:272NzLZEDL67Y2riuAkya9gnXgAicZxH",
                                "proof": [{
                                    "created": "2020-11-06T11:57:32Z",
                                    "creator": "did:gatc:272NzLZEDL67Y2riuAkya9gnXgAicZxH#keys-1",
                                    "proofPurpose": "authentication",
                                    "proofValue": "44DbZZkpwxMshjxH14XlHxzdXL9pC4MbmdJSP7KwKwk-BzK5oSnQpIH2jSYn84GPs1EGdLmbQcVdo-42HaHwBw",
                                    "type": "Ed25519Signature2018"
                                }],
                                "type": ["VerifiableCredential", "academicInstitutionCredential"]
                        }]
                    }   
                }
            

The Presentation Response MUST be sent to the Verifier domain stated on the Presentation Request. The sharing of the message SHOULD be done using an HTTP POST request to the specific path /api/v1/presentations.

                    
                        POST /api/v1/presentations HTTP/1.1
                        Host: $presentationRequest.callback
                        Content-Type: application/json
    
                        {
                            //Presentation Response ...
                        }
                    
                

Allow configuration and discovery of non-standard paths for presenting Presentation Responses.

Pairwise DIDs

The Verifiable Presentation on Presentation Responses MUST be signed exclusively with a Pairwise DID.

Revoking the Pairwise DID SHOULD automatically render invalid any future presentation containing signed by it. Pairwise DIDs MUST only be revoked by the Subject as its rightful Owner.

For tracing the PairWise DID to the AnyWise DID stated on the subject of the credentials, see .

Verifiable Consent

The Verifiable Consent is a [[JSON-LD]] document signed by both parties. It MUST be exchanged prior to sending any Presentation Response.

The goal of the consent is cuadruple:

There are other efforts to manage consents. See Hiperledger Indy, JLINC Protocol. Those efforts seem to be either too dependant on the technology stack, either restricted in capabilities compared to the goals of this document.

Id

A consent MUST have an unique id representing the relation between the Holder and the Verifier.

The consent identifier MUST correspond to PairWise DID of the relation.

The identifier MUST be confirmed by signing the document with the PairWise DID.

Approver Subject

The approverSubject MUST refer to a non-repudiable DID from the Subject, that SHOULD be present on the subject of all the credentials shared.

The approverSubject MUST be proved by signing the document with one of his private keys.

Authorized Entity

The authorizedEntity MUST be stated as the DID requesting the

The authorizedEntity MUST be proved by signing the document with one of his private keys.

Claims

Each of the verifiable credentials that have been exchanged between the Holder and the Verifier.

The credential content is NOT REQUIRED on the consent, just its identifier. Both the type and the purpose MUST be stated.

ProofChain
As defined in [[LD-PROOFS]]

Consider Credential Delegation processes on Consent.

                
                    {
                        "approverSubject": "did:gatc:YjcwNDgzMWU1ODA0ZmU2NDU0MjU0YzNl",
                        "authorizedEntity": "did:gatc:22bhyz2xdJbKV2ZLUpedzqXbSoh9Gofw",
                        "claims": [{
                            "credentialId": "cred:gatc:tqn2onxicmlezcmollcdkmjgyrj53b1x1086",
                            "purpose": "authentication",
                            "type": "studentIdCredential"
                        }, {
                            "credentialId": "cred:gatc:4npxte79gk55zis44339zast75dq94mjqmyk",
                            "purpose": "application",
                            "type": "lastNameCredential"
                        }, {
                            "credentialId": "cred:gatc:0w334gdrx87duqanp1eymfzlcyh22g0ox32z",
                            "purpose": "application",
                            "type": "firstNameCredential"
                        }, {
                            "credentialId": "cred:gatc:a00loy0pcfkdiq6tx9sburq5a2jl6r1z2icc",
                            "purpose": "authentication",
                            "type": "academicInstitutionCredential"
                        }],
                        "id": "did:gatc:OTk5ZDIxNjEzYjBlNWViN2VlNjRhNTJi",
                        "proofChain": [{
                            "created": "2020-11-06T12:48:58Z",
                            "creator": "did:gatc:OTk5ZDIxNjEzYjBlNWViN2VlNjRhNTJi#keys-1",
                            "proofPurpose": "nonRepudiation",
                            "proofValue": "7zf4bX99NnmJ-VIfV7SGoKk092Vqb_mTBwHqpO3o4WLIZy2SByjVorVNOOa0GjkzoTCiKN-Nh4SiLuCAyqwrCQ",
                            "type": "Ed25519Signature2018"
                        },
                        {
                            "created": "2020-11-06T12:48:58Z",
                            "creator": "did:gatc:YjcwNDgzMWU1ODA0ZmU2NDU0MjU0YzNl#keys-1",
                            "proofPurpose": "nonRepudiation",
                            "proofValue": "mkQ1zTl5Lw25m1pXKo1pTnGLeV_L7pqC5oPqlA0JCxOMWq5VIFg2KeORACv-SuOmCBsxZKaRg7MBeqYIBU9iyY",
                            "type": "Ed25519Signature2018"
                        },
                        {
                            "created": "2020-11-06T12:49:12Z",
                            "creator": "did:gatc:22bhyz2xdJbKV2ZLUpedzqXbSoh9Gofw#keys-1",
                            "proofPurpose": "nonRepudiation",
                            "proofValue": "8zb45X9NxmG-3jl6vgUXcAimLfu7o53N9Pt17-DksvA0zom2w2m2w2DOd18qh42mkyFNGvxzLk91udO61Ptvu2",
                            "type": "Ed25519Signature2018"
                        }
                        ]
                    }
                

Enforcing Consent

Presentation responses MUST be signed with a PairWise DID with the same Id of the Verifiable Consent.

A Verifier MUST possess a consent with the ID of a Pairwise DID before receiving a Presentation Response signed by that DID.

A Verifier receiving a from a Pairwise DID from which he does not possess the consent MUST NOT be able to assert the relation between the Subject of the credentials and the signer of the presentation. Those presentations MUST then be considered invalid.

Intercepting, inspecting or receiving one or more Presentation Responses is not a valid proof of relation between a Holder and a Verifier without access to the Verifiable Consent.

Consents SHALL be modified or revoked by any of the two parties.

Consent Exchange Protocol

Upon receiving a Presentation Request from a Verifier from which no previous relation has been stablished, before generating the presentation response, it is the duty of the Holder to create a new Verifiable Consent based on both:

The Verifiable Consent must the be signed twice by the Holder, first with the Pairwise DID and then the Anywise DID.

The Consent MUST then be sent to the Verifier domain stated on the Presentation Request. The sharing of the message SHOULD be done using an HTTP POST request to the specific path /api/v1/consents.

                
                    POST /api/v1/consents HTTP/1.1
                    Host: $presentationRequest.callback
                    Content-Type: application/json

                    {
                        //Verifiable consent ...
                    }
                
            

The Verifier MUST respond either:

Only after having received and stored a consent signed by the Verifier SHALL the Holder respond to the Presentation Request with a Presentation Response.

sequenceDiagram Verifier->>Holder: Presentation Request Holder-->>Holder: Previous consent for this verifier? opt No previous Consent Holder-->>Holder: Select adequate credentails Holder-->>Holder: Create new consent Holder-->>Holder: Sign new consent Holder->>+Verifier: Send signed consent Verifier ->>-Holder: Return signed consents Holder-->>Holder: Store signed consent end Holder ->>Verifier: Presentation Response Verifier ->>Verifier: Previous consent for this Pairwise DID alt Existing Consent Verifier->>Verifier: Verify presentation else Verifier->>Verifier: Invalid presentation end
Consent Exchange Protocol

Allow configuration and discovery of non-standard paths for exchanging consents.

Consent Modification Protocol

This section is still to be defined