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

Verifiable Credential (VC)

As defined in [[VC-DATA-MODEL]].

Verifiable Presentation (VP)

As defined in [[VC-DATA-MODEL]].

Linked Data Proofs

As defined in [[LD-PROOFS]].

Presentation Exchange

As defined in [[VUI-PRESENTATION-EXCHANGE]]

Presentation Definition

As defined in [[VUI-PRESENTATION-EXCHANGE]]

Presentation Submission

As defined in [[VUI-PRESENTATION-EXCHANGE]]

Data Protection Impact Assessments (DPIA)

As defined in GDPR - DPIA

(Automated) Data Agreements (ADA)

As defined in [[ADA]]

Data Agreement Template

See Data Model

Data Agreement Record

See Data Model

Consent Receipts

As defined in [[KANTARA-CONSENTS]]

Verifiable Consents(VCON)

As defined in [[VERIFIABLE-CONSENTS]]

JSON-LD

As defined in [[JSON-LD]]

Verifier Universal Interface(VUI)

As defined in [[VUI]]

Data Agreement Template

The Data Agreement Template is the base model to generate a Data Agreement. It MAY be offered by the Verifier to the Holder at the initiation of a Presentation Exchange.

Its contents MUST match the presentation definition to be processable

Properties

Template Id

The template id references univocally the Data Agreement Template. It SHOULD be linked to a specific presentation definition.

Template Version

The template version allows to keep tracking of updates on the Data Agreement template.
Holders MUST use the version to determine if they need to perform changes on an existing Data Agreement Record

Data Receiver

The data receiver MUST inform the user of all the information about the service provided and the usage of the data.

Id

DID associated to the service provider

Name

Name of the Service Provider to inform the Holder

Service

OPTIONAL: Description of the service that will make use of the data

URL

Base URL of the digital service provided to interact along the lifecycle of the data agreement

Consent Duration

Default duration of the data agreement if no further operations happen. After expiration, the data MAY be kept for regulation reasons, but not used or exploited any more.

Form of consent

OPTIONAL: Describes the way the holder needs to provide his consent. Either

• 'explicit'
• 'implicit'

Default is 'explicit'

Purposes

Id

Unique identifier of the purpose to use it as a reference

Purpose Description

Description of the purpose for which the data will be used

Purpose Category

Data privacy category under which falls this purpose of usage.

Credential purposes SHALL provide support for GDPR and other privacy regulations. Vocabulary MUST be in line with Data Privacy Vocabulary. The list of all accounted purposes has been used as a base for this selection.

The category MUST be one of the following:

• 'Identify verification'
• 'Fraud detection and prevention'
• 'Access control'
• 'Service Provision'
• 'Service Optimization'
• 'Service Personalisation'
• 'Marketing'
• 'Commercial Interests'
• 'Research & Development'

Legal basis

Legal basis employed by the service provider for the usage of this data. One of:

• 'consent'
• 'legal_obligation'
• 'contract'
• 'vital_interest'
• 'public_task'
• 'legitimate_interest'

Method of use

OPTIONAL Indicate the Holder how the data will be processed by the Verifier

• "none"
• "data-source"
• "data-using-service"

Data Policy

Data Retention Period

Time during which the data MAY be kept by the service provider, even after extinction of the consent.

Industry Scope

OPTIONAL Economic sector representing the service provided.

Geographic Restriction

OPTIONAL Geographic region where the data will be managed.

Jurisdictions

OPTIONAL List of legal jurisdictions under which the data will be used.

Policy URL

URL pointing to the privacy policy of this service

Storage Location

OPTIONAL Physical location of storage where the Data will be stored

Personal Data

Attribute name

Name describing univocally the attribute.

It MUST refer to an input descriptor ID on the associated Presentation Definition

Attribute sensitive

boolean Marks if this piece of information must be managed as sensitive information

Purposes

List of purposes, referenced by their Id, under which this credential CAN be used.

DPIA

OPTIONAL: Information about the DPIAs performed with the generic defined scopes if they have been performed

Timestamp

Time at which the DPIA was performed

URL

Url to retrieve the DPIA report

Event

The events will track all the lifecycle and interactions performed on the Data Agreement by the different parties.

Principle Did

DID of the actor performing the data agreement operation

State

Current state of the Data Agreement. MUST be one of the following:

• 'Definition'
• 'Preparation'
• 'Capture'
• 'Modification'
• 'Revocation'

Version

Version of the Data Agreement at the time the Event is performed

Timestamp

Time of operation of the Data Agreement

Proof

Data Proof asserting the event and the current resulting state of the Data Agreement, as described in VC Data Model. One or more cryptographic proofs that can be used to detect tampering and verify the authorship of a modification or acceptance event.

                     
        {
            "@context": "https://schema.igrant.io/data-agreements/v1",
            "data_receiver": {
                "id": "did:gatc:24vXYrJLHzoEuooa7xV6AZG2wc6tZSfH",
                "consent_duration": 365,
                "form_of_consent": "explicit",
                "name": "Bank Of America Fake",
                "service": "Bank Of America Demo",
                "url": "https://9ae1-88-6-127-11.ngrok.io"
            },
            "event": [{
                "principle_did": "did:gatc:24vXYrJLHzoEuooa7xV6AZG2wc6tZSfH",
                "proof": [{
                    "created": "2022-01-13T07:48:40Z",
                    "creator": "did:gatc:24vXYrJLHzoEuooa7xV6AZG2wc6tZSfH#keys-1",
                    "domain": "gataca.io",
                    "nonce": "kX04XcM-rpYN4kDopwjaCX-ocxRwzrRs9R_DtsySghs=",
                    "proofPurpose": "assertionMethod",
                    "signatureValue": "fRx1WYGM_77VS_7m6SA4hpmmQdT_keIlTABeDY-FA1rQXSe0_zgSDdmVAzcegUJ23jfbKrZY_6EEYrTaode5Dg",
                    "type": "JcsEd25519Signature2020",
                    "verificationMethod": "did:gatc:24vXYrJLHzoEuooa7xV6AZG2wc6tZSfH#keys-1"
                }],
                "state": "Preparation",
                "version": "0",
                "timestamp": 1642060120223
            }],
            "personal_data": [{
                "attribute_name": "email",
                "attribute_sensitive": true,
                "purposes": ["Client authentication"]
                }, {
                "attribute_name": "debtRecords",
                "attribute_sensitive": true,
                "purposes": ["Client authentication","Special clients promotion"]
            }],
            "purposes": [{
                "data_policy": {
                    "data_retention_period": 300,
                    "geographic_restriction": "Europe",
                    "industry_scope": "Banking",
                    "jurisdictions": ["Spain", "EU"],
                    "policy_URL": "https://bank.demo.gataca.io/privacy-policy/",
                    "storage_location": "Europe"
                },
                "id": "Client authentication",
                "legal_basis": "legal_obligation",
                "method_of_use": "data-source",
                "purpose_category": "Identify verification",
                "purpose_description": "Authenticate the user to provide services"
            }, {
                "data_policy": {
                    "data_retention_period": 30,
                    "geographic_restriction": "Europe",
                    "industry_scope": "Banking",
                    "jurisdictions": ["Spain", "EU"],
                    "policy_URL": "https://bank.demo.gataca.io/privacy-policy/",
                    "storage_location": "Europe"
                },
                "id": "Special clients promotion",
                "legal_basis": "legitimate_interest",
                "method_of_use": "data-using-service",
                "purpose_category": "Service Personalisation",
                "purpose_description": "Collecting user data for offering specific promotions"
            }],
            "template_id": "x76ShERoQReZmWlLdJZWhWmWQx8bhGa",
            "template_version": "v1.0",
        }
        
            

Data Agreement Record

The Data Agreement Record is an extension of the Data Agreement Template.

The Holder fills the template offered by the verifier with his personal data and the attribute unique ids that are being shared in that exchange.

Even if the Holder has multiple pieces of information satisfying the Verifier requirements, the Id of the one selected MUST be referenced in the Data Agreement without disclosing its contents.
This is necessary to enforce Data-minimization, and ensure that the Verifier only has rights to use the specific information shared by the Holder, and not any other of that same type that could also come from the same Subject.

The Data Agreement Record represents the current accepted state of a Data Agreement by both parties.
It SHOULD be used to maintain the lifecycle of the credential exchange performed between the Holder and the Verifier.

The Data Agreement Record MUST be kept at its last version by both the Holder and the Verifier. Previous versions of the Data Agreement are RECOMMENDED to be stored at least by Verifiers.

Properties

The additional properties added to the template are:

Id

Unique ID to reference this Data Agreement

Version

Current version of the Data Agreement Record

Data Holder

DID uniquely referencing the Holder of the credentials, performing the exchange.
It MAY be the same as the Data Subject. If using Peer DIDs for exchanges, it MUST be the Peer DID.

Data Subject

DID uniquely referencing the real persona to which the credentials used on the credential exchange have been issued.
It MAY be the same or different as the Data Holder.

Personal Data

Inside the personal data information, the following field MUST be included

Attribute Id

Unique reference to the Id of the Verifiable Credential shared satisfying this kind of information.
The credential Id MUST match the Id of the Credential that satisfies the Input Descriptor matching the Attribute name of this same piece of personal data

Termination timestamp

If present, it signalates that this Data Agreement Record is not in use anymore with the timestamp at which it was revocated.

             
{
    "@context": "https://schema.igrant.io/data-agreements/v1",
    "data_holder": "did:gatc:NjBjNWJiNmY1ZjQ2NDYyZjk0Zjg0YWI4",
    "data_receiver": {
        "id": "did:gatc:24vXYrJLHzoEuooa7xV6AZG2wc6tZSfH",
        "consent_duration": 365,
        "form_of_consent": "explicit",
        "name": "Bank Of America Fake",
        "service": "Bank Of America Demo",
        "url": "https://9ae1-88-6-127-11.ngrok.io"
    },
    "data_subject": "did:gatc:YzQxNjRjM2U4YTUzZGVkNjhmNjAxYzk5",
    "event": [{
        "principle_did": "did:gatc:24vXYrJLHzoEuooa7xV6AZG2wc6tZSfH",
        "proof": [{
            "created": "2022-01-13T07:48:40Z",
            "creator": "did:gatc:24vXYrJLHzoEuooa7xV6AZG2wc6tZSfH#keys-1",
            "domain": "gataca.io",
            "nonce": "kX04XcM-rpYN4kDopwjaCX-ocxRwzrRs9R_DtsySghs=",
            "proofPurpose": "assertionMethod",
            "signatureValue": "fRx1WYGM_77VS_7m6SA4hpmmQdT_keIlTABeDY-FA1rQXSe0_zgSDdmVAzcegUJ23jfbKrZY_6EEYrTaode5Dg",
            "type": "JcsEd25519Signature2020",
            "verificationMethod": "did:gatc:24vXYrJLHzoEuooa7xV6AZG2wc6tZSfH#keys-1"
        }],
        "state": "Preparation",
        "version": "0",
        "timestamp": 1642060120223
    }, {
        "principle_did": "did:gatc:NjBjNWJiNmY1ZjQ2NDYyZjk0Zjg0YWI4",
        "proof": [{
            "created": "2022-01-13T07:50:12Z",
            "creator": "did:gatc:NjBjNWJiNmY1ZjQ2NDYyZjk0Zjg0YWI4#keys-1",
            "proofPurpose": "authentication",
            "signatureValue": "uWl5t_KSV09qG5nv5Opk0A-r0WoNKkeY9otdxA43sPwQFK4ZACVCKKT0bockbUYAhXm-SGBhQ45xlBwgH-GXDw",
            "type": "JcsEd25519Signature2020",
            "verificationMethod": "did:gatc:NjBjNWJiNmY1ZjQ2NDYyZjk0Zjg0YWI4#keys-1"
        }],
        "state": "Capture",
        "version": "1",
        "timestamp": 1642060212916
    }],
    "id": "3Nkep8bQygtyWyrmcJDkmnnmH8W1huJpZ4E2i6WyY1da",
    "personal_data": [{
        "attribute_id": "cred:gatc:NjMxNjc0NTA0ZjVmZmYwY2U0Y2M3NTRk",
        "attribute_name": "email",
        "attribute_sensitive": true,
        "purposes": ["Client authentication"]
        }, {
        "attribute_id": "urn:credential:hEoISQtpfXua6VWzbGUKdON1rqxF3liv",
        "attribute_name": "debtRecords",
        "attribute_sensitive": true,
        "purposes": ["Client authentication","Special clients promotion"]
    }],
    "purposes": [{
        "data_policy": {
            "data_retention_period": 300,
            "geographic_restriction": "Europe",
            "industry_scope": "Banking",
            "jurisdictions": ["Spain", "EU"],
            "policy_URL": "https://bank.demo.gataca.io/privacy-policy/",
            "storage_location": "Europe"
        },
        "id": "Client authentication",
        "legal_basis": "legal_obligation",
        "method_of_use": "data-source",
        "purpose_category": "Identify verification",
        "purpose_description": "Authenticate the user to provide services"
    }, {
        "data_policy": {
            "data_retention_period": 30,
            "geographic_restriction": "Europe",
            "industry_scope": "Banking",
            "jurisdictions": ["Spain", "EU"],
            "policy_URL": "https://bank.demo.gataca.io/privacy-policy/",
            "storage_location": "Europe"
        },
        "id": "Special clients promotion",
        "legal_basis": "legitimate_interest",
        "method_of_use": "data-using-service",
        "purpose_category": "Service Personalisation",
        "purpose_description": "Collecting user data for offering specific promotions"
    }],
    "template_id": "x76ShERoQReZmWlLdJZWhWmWQx8bhGa",
    "template_version": "v1.0",
    "version": "1"
}
                            
            

Creation

The generation Data Agreement MUST be performed along a new Presentation Exchange. With any presentation exchange, a Data Agreement Template with a given Id and Version SHOULD be attached.

The Holder SHOULD check for existent Data Agreement Records belonging to the same data receiver id.

• If these are non-existent, then a new Data Agreement MUST be created.
• If there are is one or more existing record, but with a different template_id, then a new Data Agreement MUST be created.
• If there is one existing with the same template_id, the template_version MUST be checked to see if a modification is required or if the last existent Data Agreement Recordcan be used

The process to generate a new Data Agreement would be:

1. Assign a new random Id and set the version to 1
2. Fill the Data Agreement Record with the attribute ids of the selected credentials matching the Presentation Definition
3. Add an event with status Preparation with the new version and sign it with the Holder DIDs
4. Only if the Holder DID is different than the Subject DID:
   Add an event with status Preparation with the new version and sign it with the Subject DID
5. Send it to the Verifier
6. 1. Verify that all the requirements are filled.
   2. Add an event with status Capture with the version 1 and sign it with the Verifier DID
   3. Store the new version of the Data Agreement Record
   4. Return the updated Data Agreement Record to the Holder
7. Store in the wallet the updated and approved Data Agreement Record to use it on current or next presentation exchanges.

Modifications

The Data Agreement MAY be modified along time with new needs from both the Holder or the Verifier.

Any modifications of the Data Agreement MUST be performed along a new Presentation Exchange.

This table shows the different kind of modifications that can be performed on a Data Agreement:

                             +-------------------------------------++-------------------------------------+
                             |            Holder                   ||               Verifier             |
                             +-------------------------------------++-------------------------------------+
                            +-----------------------------------------------------------------------------+ 
                            |+-------------------------------------++------------------------------------+|
                            || Replacing shared credentials        || Asking for a different set of      ||
                            ||  with an equivalent                 || credentials                        ||
                            ++------------------------------------++-------------------------------------++
                            || Revoking access to some credentials || Modifying the credential purposes  ||
                            || => Partial Revocation               ||                                    ||
                            ++---------------------------------------------------------------------------++
                            |                                                                             |
                            |           End of relationship => Full revocation                            |
                            |                                                                             |
                            +-----------------------------------------------------------------------------+
                        

Modifications of the Data Agreement MUST result in a higher version of the Data Agreement Record

Every version of the Data Agreement Record MUST be signed by both the Verifier and the Holder. Every stable Data Agreement Record MUST contain at least 2 events with the current version, each signed by a different Actor.

Modifications by the Holder

The Holder CAN only modify some credentials, depending on the Category of the Purpose assigned to the credential.

This table is not a final definition.
The protocol of substitution or partial revocation of a specific purpose would be better configured at purpose level. It hasn't been suggested in the data model to avoid major divergencies with the Consent Receipts and ADA specifications.

The process to modify a Data Agreement would be:

1. Update the Data Agreement version
2. Perform the allowed modifications
3. Add an event with status Preparation with the new version and sign it with the Holder DIDs
4. Send it to the Verifier
5. 1. Verify that all modifications are allowed.
   2. Add an event with status Capture with the new version and sign it with the Verifier DIDs.
   3. Store the new version of the consent record.
   4. Return the updated Data Agreement Record to the Holder
6. Store in the wallet the updated and approved Data Agreement Record to use it on current or next presentation exchanges.

Modifications by the Verifier

The process to modify a Data Agreement would be:

1. Update the Data Agreement Template version
2. Perform the requested modifications
3. Update the Data Agreement version
4. Add an event with status Definition with the new version and sign it with the Holder DIDs
5. Send it to the Holder
6. 1. Decide if accept the requested modifications
   2. Fill the data agreement and the associated Presentation Exchange like in the Creation process
   3. Store the new version of the consent record.
   4. Return the updated Data Agreement Record to the Verifier
7. Store the new Version of the Data Agreement Record in the Verifier storage to use it on current or next presentation exchanges.

Revocation

The full revocation of the Data Agreement CAN be requested by both parties.

The process of revocation is done by sending a Data Agreement Record with the last known version with a termination timestamp and a new Event of status Revocation signed by the requester. The receiver MUST also add a new Event of status Revocation signed by the him. Both parties MAY store later the Data Agreement Record as proof of termination.

Consequences

The provision of the data-using-service to the Subject MAY end after the acceptance of the revocation.

The usage of the data MAY be done up until the expiration of the Consent, as accepted in the first version.
The storage of Data MAY be executed for each specific purpose until it was accepted on the Data Agreement.

For security reasons, if using a Peer DID as a Holder for the Data Agreement, it is RECOMMENDED to also revoke the DID. In that case, further exchanges of this data CANNOT be trusted by the Verifier, rendering it unusable.