Try   HackMD

DIF - Data Agreement Specification

Table of Contents

Introduction

<The key question being asked is how do we connect presentation exchange to the key motivations identified below? >

This document is divided into 3 main sections:

  1. Data Agreement Process
  2. Data Agreement Schema
  3. Interoperability

The data agreement process section is a high level view of the steps that take place when working with data agreements. Not all steps may apply to signing data agreements but are included to help understand what an organization wanting to support data agreements need to consider. For example definition of a schema and how to populate the data agreement prior to signing.

The data agreement schema section describes the details of the data agreement and content. All the fields are explained and also notion of an envelop to wrap the data agreement when signing.

The interoperability section describes how for each of the supported methods how data agreements are exchanged and signed. Important in this section is to establish the requirements to reach interoperability between different vendors.

Terms and Concepts

example describe consent, DID, W3C etc.

Motivation

<What are the key motivations of needing a data agreement? and what exists today?>

For any organisation, processing personal there are key reasons for introducing the concept of data agreement as part of regulating the use of personal data. As Lawrence Lessig has previously established (known as Lessig's "modalities of regulation", the Internet is regulated by multiple forces. The motivation for introducing Data Agreements could take a similar approach:

  1. Data laws
  2. Ethics and norms
  3. Standards
  4. Architectures

This provides a global perspective to Data Agreements and could potentially work across multiple jurisdictions, both in countries where stricter and sophisticated legal frameworks as well as where data laws are emerging or non-existant.

Regulatory compliance and data rights

Regulatory compliance forms a key aspect of introducing data agreements (e.g. GDPR). In GDPR, the key articles that are taken as input are:

  • Article 4: Definitions
  • Article 6(1): Lawfulness of processing
  • Article 7: Conditions for consents
  • Article 30: Records of processing

Norms, ethics and trust frameworks

The second key driver is ethical norms that are prevalent in any society. These may be based on certain standards or ethical norms such as, e.g., MyData or FAIR Data Principles. s.

Standards

Data agreements are also influenced by standards and this section highlights some of those influencing the development of data agreement. Some of the ISO standards are mentioned and since it is generic to any regulation and not only GDPR then it will use their own terms. To get an introduction of those terms standard ISO/IEC 29100 (Privacy Framework) is a good start, it is also free.

ISO/IEC 29100 (Privacy Framework)

The ISO/IEC 29100 standard provides a high-level framework for protecting personal data or personal identifiable information (PII) as defined in ISO standards. The standard helps specify privacy terminology, actors and roles in processing personal data, privacy safeguards requirements and reference to privacy principles which are frequently referred to by management standards.

An important aspect to provide a notice and get consent is the adherence to the privacy by design principles listed below. Each principle is reviewed if they should be communicated by an organisation to an individual (data subject in GDPR terms).

Privacy Principles Communication with Individual
Consent and choice Record of choice
Purpose, legitimacy and specification Clear expression of purpose
Collection limitation Explicit list of personal data used for specified purpose
Data minimization Similar to collection limitation but how implemented in a system
Use, retention and disclosure limitation Explicit indication of retention period for collected personal data
Accuracy and quality Not applicable
Openness, transparency and notice Notice of purpose and transparency of the communication
Individual participation and access How to exercise privacy rights by individual
Accountability Not applicable
Information security Informing individual of potential privacy risk
Privacy compliance Demonstration of privacy regulation compliance for increased trust

The ISO/IEC 29184 standard specifies the controls that set the structure of online privacy notices and getting consent.

The standard will further be elaborated in the data model section.

The ISO/IEC 27560 standard specifies the structure of a consent record (data agreement) and receipt. The work is based on Kantara consent receipt specification.

The standard will further be elaborated in the data model section.

Architectures

  • PIMS (Personal information management system)

Data Agreement Process

To automate compliance and increase trust assurance, a Data Protection Impact Assessment (DPIA) or similar may be used to populate the data agreement.

A DA lifecycle consists of 4 phases as illustrated in the figure below:


Figure 11: Data Agreement (with consent as a lawful basis, for e.g.) Lifecycle

Definition: In this phase, the organisation (a DS or a DUS) adopts and defines a data policy that applies to the healthcare industry in its jurisdiction as a template.

Preparation: In this phase, the organisation (a DS or a DUS) that intends to process personal data configures the DA and relevant rules for its use. An organisation could use personal data for third-party data sharing as an example. If the data processing is based on consent, the lawful_basis in the DA schema definition is of type consent.

In this phase, an organisation (admin) registers their data model. It configures the DA that consists of the usage purpose, the data attributes used by the agreement, legal basis, data policy configurations etc. In this case, the lawful basis for the data agreement is "Consent". Once prepared, the organisation publishes the DAs to the individuals. Refer here for the complete schema vocabulary of the latest DA.

Capture: In this phase, the individual can review the DA. Once agreed upon, it is captured in a data agreement record by both the organisation and the individual as a cryptographic signature and stored for verification. This allows an auditor to check and ensure records are in place to process the individual's personal data. This phase could also encompass delegation and other individual use cases.

The individuals can view the relevant granularity levels (aka attribute level, e.g. name, activity data, phone number etc.) of respective data. It allows individuals to exercise their rights (as per GDPR Article 12-23) and opt-in / opt-out of any data usage at various granularity levels, where consent is used as a lawful basis.

The capture can happen actively or passively. Active capture is when the individual is involved in real-time during the data exchange transaction. E.g. when a patient shares data with a nurse during remote support (such as with 1177 in Sweden). In passive capture, the individual has granted permission to either a DS or a DUS to share or consume their personal data. For example, when a patient has given consent for anonymised and/or pseudonymised data usage by researchers, the patient can always revoke the agreement at any point (e.g. if the lawful_basis is of type consent). Passive capture of consents can be anonymous or identifiable and transparent based on the DUS’s DA configurations.

Proof: In this phase, an organisation (a DS or a DUS) can demonstrate that a valid record exists for performing data processing within itself or with other organisations. This allows internal usage, and an auditor can verify and ensure records are in place to process the individual's personal data.

Key actors and use cases

  • Who are the actors involved in a data exchange or any data processing transaction?
    • Individual data subject
    • Data Controller
    • Data Processor (used synonymous with Data Controller)
    • Third party
    • Authority
  • What are the key usecases?
    • Notice preparation
    • Basic notice and consent
    • Update due to change in notice
    • Exercise privacy rights
      • Withdrawal by individual
      • Termination by data controller
      • Other?
    • [not in scope] Demonstate consent to authority

Use Case: Notice Preparation

In the preparation phase the notice information that will be extracted from the data agreement needs to be set. There may be a templaet database to choose from.

Questions:

  1. Agree on signing in this order

Questions:

  1. [Lal] How to reflect the choice of optional attributes in notice?
  2. [Jan] Add information like images or health records?

Data Agreement Schema

Description of the two basic documents used to stablish a data agreement and the set of properties to be included in each of them.

AP: add grouping of the attributes

The data agreement will be conveyed by some means described in the interoperability section. To seperate the implementation and the data agreement schema we introduce the term "envelope" to signify the transport of the data agreement as illustrated in the below diagram.

The content of the data agreement contained in the envelope is represented in the following diagram. How the fields are structured may vary but in general they should be included. [NOTE-diagram will be updated as the fields are agreed upon. May need to create a cross reference table of the implementations to be able to identify misalignement]

The next three sub-sections describe the data agreement notice that is shared with the individual, the data agreement record that is signed and is proof of consent, and the common examples of the data agreement notice/record.

Data agreement notice

A data agreement template is a document elaborated by the Verifier and offered at the beginning of the exchange. Depending on the features supported, it will be presented with the requirements defined by the verifier by the exchange (i.e: if using the Presentation Exchange standard, it should be submitted with the presentation definition).

The data agreement template must define to the Holder the usage that will be given to each of the requested pieces of data, including the purpose, the storage, the privacy policy or legal information about the requester.

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

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.

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](https://dpvcg.github.io/dpv/). [The list of all accounted purposes](https://www.w3.org/community/dpvcg/wiki/Purposes_for_handling_Personal_Data#High-level_categories_.28to-be-discussed.29) 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 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 HTML StandardData 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.

Example 1: Data Agreement Template

​​​​        {
​​​​    "@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

A data agreement record is each of the accepted versions of a Data Agreement. The current Data Agreement would be the Data Agreement record with the highest version signed by both parties.

A data agreement record is built from a data agreement template: completing the template with the remaining missing data that MUST be provided by the Holder.

[]

The data agreement record MAY be submitted along a Verifiable Presentation during an Exchange. If there has previously been a valid data agreement record that requires no modifications, the submission of a new record is OPTIONAL.

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 a specific requirement by the Verifier (i.e.: if using a Presentation exchange, 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.

Example 2: Data Agreement Record

​​​​{
​​​​    "@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"
​​​​}

Common examples

Example 1

Here is an example schema from NGI eSSIF-Lab [Automated Data Exchange Project].

{
  "@context": [
    "https://raw.githubusercontent.com/decentralised-dataexchange/automated-data-agreements/main/interface-specs/data-agreement-schema/v1/data-agreement-schema-context.jsonld",
    "https://w3id.org/security/v2"
  ],
  "id": "d7216cb1-aedb-471e-96f7-7fef51dedb76",
  "version": "v1.0",
  "template_id": "91be609a-4acd-468f-b37a-0f379893b65c",
  "template_version": "v1.0",
  "data_controller_name": "Happy Shopping AB",
  "data_controller_url": "www.happyshopping.com",
  "data_policy": {
    "policy_URL": "https://happyshoping.com/privacy-policy/",
    "jurisdiction": "Sweden",
    "industry_sector": "Retail",
    "data_retention_period": "30",
    "geographic_restriction": "Europe",
    "storage_location": "Europe"
  },
  "purpose": "Customized shopping experience",
  "purpose_description": "Collecting user data for offering custom tailored shopping experience",
  "lawful_basis": "<consent/legal_obligation/contract/vital_interest/public_task/legitimate_interest>",
  "method_of_use": "<null/data-source/data-using-service>",
  "personal_data": [
    {
      "attribute_id": "f216cb1-aedb-571e-46f7-2fef51dedb54",
      "attribute_name": "Name",
      "attribute_sensitive": "True",
      "attribute_category": "Name"
    },
    {
      "attribute_id": "f216cb1-aedb-571e-46f7-2fef51dedb54",
      "attribute_name": "Age",
      "attribute_sensitive": "True",
      "attribute_category": "Age"
    }
  ],
  "dpia": {
    "dpia_date": "2021-05-08T08:41:59+0000",
    "dpia_summary_url": "https://org.com/dpia_results.html"
  },
  "event": [
    {
      "id": "did:mydata:z6MkiTBz1ymuepAQ4HEHYSF1H8quG5GLVVQR3djdX3mDooWp#1",
      "time-stamp": "2021-05-08T08:41:59+0000",
      "did": "did:mydata:z6MkiTBz1ymuepAQ4HEHYSF1H8quG5GLVVQR3djdX3mDooWp",
      "state": "<Definition/Prepration/Capture>"
    },
    {
      "id": "did:mydata:z6MkGskxnGjLrk3gKS2mesDpuwRBokeWcmrgHxUXfnncxiZP#2",
      "time-stamp": "2021-05-08T08:41:59+0000",
      "did": "did:mydata:z6MkGskxnGjLrk3gKS2mesDpuwRBokeWcmrgHxUXfnncxiZP",
      "state": "<Definition/Prepration/Capture>"
    }
  ],
  "proof": [
    {
      "id": "did:mydata:z6MkiTBz1ymuepAQ4HEHYSF1H8quG5GLVVQR3djdX3mDooWp#1",
      "type": "Ed25519Signature2020",
      "created": "2021-05-08T08:41:59+0000",
      "verificationMethod": "did:mydata:z6MkiTBz1ymuepAQ4HEHYSF1H8quG5GLVVQR3djdX3mDooWp",
      "proofPurpose": "contractAgreement",
      "proofValue": "z6MkwW6aqMnjgrhJXFUko3NnZPGzVpkNzhYK7yEhnsibmLwLz6MkwW6aqMnjgrhJXFUko3NnZPGzVpkNzhYK7yEhnsibmLwL"
    },
    {
      "id": "did:mydata:z6MkGskxnGjLrk3gKS2mesDpuwRBokeWcmrgHxUXfnncxiZP#2",
      "type": "Ed25519Signature2020",
      "created": "2021-05-08T08:41:59+0000",
      "verificationMethod": "did:mydata:z6MkGskxnGjLrk3gKS2mesDpuwRBokeWcmrgHxUXfnncxiZP",
      "proofPurpose": "contractAgreement",
      "proofValue": "z6MkGskxnGjLrk3gKS2mesDpuwRBokeWcmrgHxUXfnncxiZPz6MkGskxnGjLrk3gKS2mesDpuwRBokeWcmrgHxUXfnncxiZP"
    }
  ],
  "principle-did": "did:mydata:z6MkGskxnGjLrk3gKS2mesDpuwRBokeWcmrgHxUXfnncxiZP"
}

Interoperability

Sections describes the implementations of data agreements into SSI technology stacks.

The following table is an overview of different methods to convey credentials and personal data. The methods that have an implementation of data agreements are listed in sub-sections.

Methods 1: JWT Envelope 2: VC-DI Envelope 3: DIDComm 4: XML
Signature 1-only (one inside other) in vp-jwt Proof object(s) in VP object ? XML-DSig (XaDES)
VP Protocol OIDC4VP (or WACI) VP Req DIDComm ?**
Authorization preference OAuth2 tokens ZCaps
Trust Establishment

* = May be possible, to be researched
** = Note - Check how some groups in the vcedu group may be implementing their education credentials. Refer to https://w3c-ccg.github.io/vc-ed/

Method 1: JWT Envelope (DID-SIOP)

https://identity.foundation/did-siop/ DID-SIOP

Presentation Exchange

https://identity.foundation/presentation-exchange/
Extensions on the Presentation Exchange Data Model to support template and records

Implementation references

  • GATACA (Spain)
  • <Please add>

Method 2: DIDComm

Description of the use of decorators to support a presentation exchange

Did Method

Description of the DID Method design to support data agreements

Implementation references

Method 3: XML

Implementation references

  • Right Consents (EU)
  • <Please add>

Example

Here is an example of consent context and consent receipt from Right Consents [Right Consents Project].

The consent context is a basis for consent transaction generation. It contains all pointers to target subject, data controller, processings and layout of what is going to be collected.

{
  "subject": "96acec87-5beb-449b-8969-07d799fad183",
  "layoutData": {
    "type":"layout",
    "elements":["4ce9cbaa-52ec-43e5-b1ec-e8667c454a9a", "9d9b8e61-3522-4a08-96d8-26ffc14fb359"],
    "orientation":"VERTICAL",
    "info":"information.001"}
}

At the end of the consent transaction, an XML receipt is generated with certified timestamp and signature (not in the sample). Attachments can also be included.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<receipt>
    <transaction>1zU5wMN2yBuCLxLmu837K</transaction>
    <jurisdiction>Jurisdiction Content</jurisdiction>
    <language>fr</language>
    <date>2022-07-01T10:09:11.553372Z[UTC]</date>
    <expirationDate>2022-12-29T10:09:11.553372Z[UTC]</expirationDate>
    <processor>https://www.fairandsmart.com</processor>
    <subject>96acec87-5beb-449b-8969-07d799fad183</subject>
    <subjectInfos/>
    <dataController>
        <address>Controller Address</address>
        <company>Controller Company Name</company>
        <email>controller@email.com</email>
        <info>Info about controller</info>
        <phoneNumber>0123456789</phoneNumber>
    </dataController>
    <headerNotice>Header information before consent content</headerNotice>
    <consents>
        <processingConsent>
            <type>processing</type>
            <key>4ce9cbaa-52ec-43e5-b1ec-e8667c454a9a</key>
            <serial>U4jTExf.U6bgLqV</serial>
            <value>refused</value>
            <title>Processing title</title>
            <data>Data processed description</data>
            <retention>
                <fullText>Data retention period explanation</fullText>
                <label>Data retention label</label>
                <unit>MONTH</unit>
                <value>3</value>
            </retention>
            <usage>Processing data usage</usage>
            <purposes>
                <purpose>CONSENT_CORE_SERVICE</purpose>
                <purpose>CONSENT_THIRD_PART_SHARING</purpose>
            </purposes>
            <containsSensitiveData>true</containsSensitiveData>
            <containsMedicalData>true</containsMedicalData>
            <controller>
                <address>Address for that particular processing</address>
                <company>Company for that particular processing</company>
                <email>controller@email.com</email>
                <info>Info</info>
                <phoneNumber>0123456789</phoneNumber>
            </controller>
            <thirdParties>
                <thirdParty>
                    <name>Third party sharing</name>
                    <value>Third party description</value>
                </thirdParty>
            </thirdParties>
        </processingConsent>
        <preferenceConsent>
            <type>preference</type>
            <key>9d9b8e61-3522-4a08-96d8-26ffc14fb359</key>
            <serial>U4jTExf.UQirUf</serial>
            <value>Option1</value>
            <label>Label 9d9b8e61-3522-4a08-96d8-26ffc14fb359</label>
            <description>Description 9d9b8e61-3522-4a08-96d8-26ffc14fb359</description>
        </preferenceConsent>
        <preferenceConsent>
            <type>preference</type>
            <key>ea4622dd-8123-4df8-919d-96d093617cd6</key>
            <serial>U4jTExf.U6NLT59</serial>
            <value>Option1</value>
            <label>Label ea4622dd-8123-4df8-919d-96d093617cd6</label>
            <description>Description of preference</description>
        </preferenceConsent>
    </consents>
    <footerNotice>Footer information</footerNotice>
    <attributes/>
    <attachments/>
    <privacyPolicyUrl>Privacy policy reference</privacyPolicyUrl>
    <collectionMethod>WEBFORM</collectionMethod>
    <confirmation>NONE</confirmation>
    <updateUrl>URL with update token for generating new transaction</updateUrl>
    <notificationType>none</notificationType>
    <validityHidden>false</validityHidden>
    <updatable>true</updatable>
</receipt>

<?xml version="1.0" encoding="UTF-8"?><receipt>
    <transaction>2M9DBTr5YkzLRLt86JGMR4</transaction>
    <jurisdiction/>
    <language>en</language>
    <date>2022-06-27T06:20:48.236810Z[UTC]</date>
    <expirationDate>2022-12-25T06:20:48.236810Z[UTC]</expirationDate>
    <processor>https://www.fairandsmart.com</processor>
    <subject>roger@localhost</subject>
    <subjectInfos/>
    <dataController>
        <address/>
        <company/>
        <email/>
        <info/>
        <phoneNumber/>
    </dataController>
    <headerNotice>General Info MyCity -</headerNotice>
    <consents>
        <processingConsent>
            <type>processing</type>
            <key>processing.001</key>
            <serial>H4dXF6P.H4FHRwd</serial>
            <value>refused</value>
            <title>Air quality warning messages</title>
            <data>We will use your first name, last name and contact details.</data>
            <retention>
                <fullText>Unless you change your mind, we will keep your choices active for: 2 an(s)</fullText>
                <label>Unless you change your mind, we will keep your choices active for:</label>
                <unit>YEAR</unit>
                <value>2</value>
            </retention>
            <usage>The purpose is to keep you informed about air quality in your neighbourhood.</usage>
            <purposes>
                <purpose>CONSENT_IMPROVED_SERVICE</purpose>
            </purposes>
            <containsSensitiveData>false</containsSensitiveData>
            <containsMedicalData>false</containsMedicalData>
            <controller>
                <address/>
                <company/>
                <email/>
                <info/>
                <phoneNumber/>
            </controller>
        </processingConsent>
    </consents>
    <footerNotice>Thank You</footerNotice>
    <attributes/>
    <attachments/>
    <privacyPolicyUrl>https://right-consents.fairandsmart.io</privacyPolicyUrl>
    <collectionMethod>PEER</collectionMethod>
    <confirmation>PEER</confirmation>
    <updateUrl>http://localhost:8089/consents/2M9DBTr5YkzLRLt86JGMR4?t=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIyTTlEQlRyNVlrekxSTHQ4NkpHTVI0IiwiZXhwIjoxNjcxOTQ5MjQ4fQ.5vhiVNjWLFEoyQSldMPKmpbHaSf_sEwoF5OAj7Z9dYY</updateUrl>
    <updateUrlQrCode>data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAASwAAAEsAQAAAABRBrPYAAAC90lEQVR4Xu2XW3LjUAhE2QH73yU7YDiNXSndpCr5mvbHJYksS8cpXg1y9F+s4rzyo13ssIsddrHDLnbYxQ672GEvrCKiouale0+zMnTZj83v3Oussch5X3NILvsxGN7pZjTRVObr8gdgkWMDclKcEs5nYIXP5PfdBfWOzIxBTkNOdouyJ5kuXfZj6OQHOyXjwPaUgqOTkU529iu1bqxQydxTIByaoucEcERqwIBKYlELJKG0VPMB2DiOkjUGNW048vEPwJAJOW45TnLnPeevu0ZsLiunDJlWG9ACxcSxY42/cn+SjFzmh899/RsfRuGDhwF6AL/JcUvefgyZzHWETJqLdqQ1D9VbsGSfJXUHpO74r0Xixig9a5dho9dXH/QxBj3YlJoQhDCkRc7fo/QmLPC22B/KrlqTubi3nRg7Y7zXzkUmGjWvox+TZOTz3EyaktojGzc2r8sRyIDqgUDUH4Cp7ihYxkhkwaUGtxkryYQhTUOuejSy81kFC0Yik0GNeDij8Jy97/swLQ7Kjmo0b5jUumbHVrw7XMbxUE/uNT+GPNb70LcfUkwTHCE4sEYw/ICVthrhkGE7hs+84RkqmX5UHRk9R40FUwi0Y8lxtWST6aecLVjRh1oWqjZSWeUcqndgqrkEEhKy4pji5/vfODE00wiFbtwco+nva/f/Y4VcEueHCLJKKEq5H4PhTxNmB8+mdzkrpkETlBwBj6JJ9fzGo/QebFxWSqViGgC22SF2jG82hYST3O78Y4/0s/QejIrTkZozRXJJ9ubbjCmNweOdoqH0iGciOKrgwFgVRbWL5TGnuk627Zj8npxScrYZX3mU7sW9GBD5FQpERF996cWalaYwimSr+HzmmV4Hht8cGTQ8RY33NCgf8WNEEFodPBrsKiEEsu7G8L6ofGAEg4i+PeYZsUIsbDSmjCLarrRjJRFr4eL3BrK3vRikNAOq0hOJRrYdC5SCXCSTXcCMQTJuxn6zix12scMudtjFDrvYYRc77K/YP7qs9qxKhfOsAAAAAElFTkSuQmCC</updateUrlQrCode>
    <notificationType>none</notificationType>
    <validityHidden>false</validityHidden>
    <updatable>true</updatable>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="xmldsig-df77c735-a63d-4b1a-b11d-33f587930250">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference Id="xmldsig-df77c735-a63d-4b1a-b11d-33f587930250-ref0" URI="">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>MA98CDLdmcyu8yfyVo74Mh4smTzAGyZBkLSVzs6iXZ8=</ds:DigestValue>
</ds:Reference>
<ds:Reference Type="http://uri.etsi.org/01903#SignedProperties" URI="#xmldsig-df77c735-a63d-4b1a-b11d-33f587930250-signedprops">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>anDA3BSgBQFuBtcRqoNrN8SwPZ0munwXRLYIMjZ0UXo=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue Id="xmldsig-df77c735-a63d-4b1a-b11d-33f587930250-sigvalue">
V/lVMHkH5JUP3n0KdPShCHM+mLFWS8bQJm1AG6hX2l/MRV5FLtR9UuahYGzTc22vwWyngzHM+1dk&#13;
wYVxpCpBRbjgSGnVHCXSFN7c8iAVVLjk0J4DgcgQyzbseZKravU+jdNRAEMiTO7YvbzI1+r9dMsi&#13;
S8TMogwJ0px5ajMSzfAXdv2EN1wAnl6nLyccB72puXIz3l9AYDRBwvCZSGATjlFewCPunOvnDVff&#13;
S4/OKirvxh3pDIU6MQVWY9q+ah1g+Ih3/jVguZub+r+PGm/SMSMR8XQNAAV1vLVw1pperAIRdfo2&#13;
KFDornnKthvXKM0u4ipUZDlzwfDpceNTqpYxrw==
</ds:SignatureValue>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
MIIDgzCCAmugAwIBAgIEJUgyvTANBgkqhkiG9w0BAQsFADByMQswCQYDVQQGEwJGUjEQMA4GA1UE&#13;
CBMHTW9zZWxsZTENMAsGA1UEBxMETWV0ejETMBEGA1UECgwKZmFpciZzbWFydDETMBEGA1UECwwK&#13;
ZmFpciZzbWFydDEYMBYGA1UEAxMPQ29uc2VudCBNYW5hZ2VyMB4XDTIwMDkwMjE1NDI0OVoXDTIy&#13;
MDgyMzE1NDI0OVowcjELMAkGA1UEBhMCRlIxEDAOBgNVBAgTB01vc2VsbGUxDTALBgNVBAcTBE1l&#13;
dHoxEzARBgNVBAoMCmZhaXImc21hcnQxEzARBgNVBAsMCmZhaXImc21hcnQxGDAWBgNVBAMTD0Nv&#13;
bnNlbnQgTWFuYWdlcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK+IKJ3hyL9Dumgh&#13;
MjWagvZu/l2Zo789YSzGhfL+NMfuj78qyGrfcN2s2XCwEiEL7CNmRhTi6O3del5f415AhjGpWT5t&#13;
tU1r0dUS3dS33RIvmaUcq8sNb6LFW7KbOHG73zj7uJQAKsMRtVhNFLTLbsSv5lGPE7C0A3nF1r1X&#13;
C/dWJoZ2SnGwC+WA3mya+yRVVi/zJAXIqlpM4siiTtD2RJv5ivFC6UqLeydfm5QLn1fPkjesDHMQ&#13;
izqjVS/PDMuYZ/w3G/NV2gl4lCX7UKy+ZGGkAbBFlp1Ekju7HcEpdPTsHQWDe37NJzMhGIgMEERO&#13;
J8zmXfTWYw2DDkhjuJNa6hUCAwEAAaMhMB8wHQYDVR0OBBYEFLXqIGMZPgQZ83Zqj/WGguf/WWQt&#13;
MA0GCSqGSIb3DQEBCwUAA4IBAQAaVIGaaR+w+zT9KFFfCQsHURyfouCNi/8m/YSnCVNOeM7hmSFx&#13;
MDY1CaiASwkQi86IGurhH2/2+c5l9vLrCX8mnWKFlA7RAMHJr2r+Jyjr3qIJlFIOi+bhW/EE91J6&#13;
IrzWfChKkA2jvKfBOG3gp5aCgEmj9e251cUYXfpz8uo1XZwQLgRdgnLlpgw1ocbDp/+ky2LqmviN&#13;
RM5HUFj0o36FJjkZkH56dekp3CYkm5vJX0HEcmh1TCm+JzDfS04Rw3XR9dxIMIkTUJfvvF1l/mDU&#13;
7M2V6q0N2VA4is0nqzMDJ49JvpYvk0pxoZdbdn/30SUYImgm1jqlGyF/TjWbcO4m
</ds:X509Certificate>
<ds:X509IssuerSerial>
<ds:X509IssuerName>cn=Consent Manager,ou=fair&amp;smart,o=fair&amp;smart,l=Metz,st=Moselle,c=FR</ds:X509IssuerName>
<ds:X509SerialNumber>625488573</ds:X509SerialNumber>
</ds:X509IssuerSerial>
<ds:X509SubjectName>cn=Consent Manager,ou=fair&amp;smart,o=fair&amp;smart,l=Metz,st=Moselle,c=FR</ds:X509SubjectName>
</ds:X509Data>
</ds:KeyInfo>
<ds:Object>
            <xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" xmlns:xades141="http://uri.etsi.org/01903/v1.4.1#" Target="#xmldsig-df77c735-a63d-4b1a-b11d-33f587930250">
                <xades:SignedProperties Id="xmldsig-df77c735-a63d-4b1a-b11d-33f587930250-signedprops">
                    <xades:SignedSignatureProperties>
                        <xades:SigningTime>2022-06-27T08:20:49.034+02:00</xades:SigningTime>
                        <xades:SigningCertificate>
                            <xades:Cert>
                                <xades:CertDigest>
                                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                                    <ds:DigestValue>effJcvsrAF5bMDFm9Idl7pgFkG2TbDTF8mbdB+Jpvc8=</ds:DigestValue>
                                </xades:CertDigest>
                                <xades:IssuerSerial>
                                    <ds:X509IssuerName>cn=Consent Manager,ou=fair&amp;smart,o=fair&amp;smart,l=Metz,st=Moselle,c=FR</ds:X509IssuerName>
                                    <ds:X509SerialNumber>625488573</ds:X509SerialNumber>
                                </xades:IssuerSerial>
                            </xades:Cert>
                        </xades:SigningCertificate>
                    </xades:SignedSignatureProperties>
                </xades:SignedProperties>
                <xades:UnsignedProperties>
                    <xades:UnsignedSignatureProperties>
                        <xades:SignatureTimeStamp>
                            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
                            <xades:EncapsulatedTimeStamp>MIIVQQYJKoZIhvcNAQcCoIIVMjCCFS4CAQMxDzANBglghkgBZQMEAgMFADCCAXwGCyqGSIb3DQEJ
EAEEoIIBawSCAWcwggFjAgEBBgQqAwQBMCEwCQYFKw4DAhoFAAQUQvVAvisebH8Y3JsuLLyZ6vQq
dWcCBAHuXTsYDzIwMjIwNjI3MDYyMDQ5WgEB/wIGAYGj0d7IoIIBEaSCAQ0wggEJMREwDwYDVQQK
EwhGcmVlIFRTQTEMMAoGA1UECxMDVFNBMXYwdAYDVQQNE21UaGlzIGNlcnRpZmljYXRlIGRpZ2l0
YWxseSBzaWducyBkb2N1bWVudHMgYW5kIHRpbWUgc3RhbXAgcmVxdWVzdHMgbWFkZSB1c2luZyB0
aGUgZnJlZXRzYS5vcmcgb25saW5lIHNlcnZpY2VzMRgwFgYDVQQDEw93d3cuZnJlZXRzYS5vcmcx
IjAgBgkqhkiG9w0BCQEWE2J1c2lsZXphc0BnbWFpbC5jb20xEjAQBgNVBAcTCVd1ZXJ6YnVyZzEL
MAkGA1UEBhMCREUxDzANBgNVBAgTBkJheWVybqCCEAgwgggBMIIF6aADAgECAgkAwemGFg2o6YIw
DQYJKoZIhvcNAQENBQAwgZUxETAPBgNVBAoTCEZyZWUgVFNBMRAwDgYDVQQLEwdSb290IENBMRgw
FgYDVQQDEw93d3cuZnJlZXRzYS5vcmcxIjAgBgkqhkiG9w0BCQEWE2J1c2lsZXphc0BnbWFpbC5j
b20xEjAQBgNVBAcTCVd1ZXJ6YnVyZzEPMA0GA1UECBMGQmF5ZXJuMQswCQYDVQQGEwJERTAeFw0x
NjAzMTMwMTU3MzlaFw0yNjAzMTEwMTU3MzlaMIIBCTERMA8GA1UEChMIRnJlZSBUU0ExDDAKBgNV
BAsTA1RTQTF2MHQGA1UEDRNtVGhpcyBjZXJ0aWZpY2F0ZSBkaWdpdGFsbHkgc2lnbnMgZG9jdW1l
bnRzIGFuZCB0aW1lIHN0YW1wIHJlcXVlc3RzIG1hZGUgdXNpbmcgdGhlIGZyZWV0c2Eub3JnIG9u
bGluZSBzZXJ2aWNlczEYMBYGA1UEAxMPd3d3LmZyZWV0c2Eub3JnMSIwIAYJKoZIhvcNAQkBFhNi
dXNpbGV6YXNAZ21haWwuY29tMRIwEAYDVQQHEwlXdWVyemJ1cmcxCzAJBgNVBAYTAkRFMQ8wDQYD
VQQIEwZCYXllcm4wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC1kQSMTkhvNOncCGJ/
wjdRYiNphLgssTC+/1F8/Dj4S85cZah02rJiGuC85+M1Y+Dt6TT9X4gjFZ8HhIgIInRgwe2IJhcG
9CgTNDWd+7gb0TU/wXlhCvGoyMhl3ADqI7Oom+a9A7qFqeyCfWBWWQXiLWpYTtE4CuFQKAzuOX6Y
oBLzgEZAB4YkQ7wHfLlfQhrzFxLZaDzbbf+688i6W6VmrlI9RZ1hdzRtTYQOJ4hrfAHFuJDXii4n
u6jdL5ooEuFX1i+SHGWWJUgGnc230G3hgd4OlXDWb4ciDOKLYoq1WQbz7gwhD3BR6PSFivi5qS0J
5Gry2culv8+tFozfYESRpLBmA7EUyvcDHwZefu76U8V180kMBZ0uMt3HasTUxMcQaDuX/Rvlkbxh
BVGG2I+aA5GzB7b5HtlU2qNvms1qHhSqLkrfF0ZLVNsY27b/4wCAJGVHNwQ2zk53uuXeb+Dz+dbn
/760YeeU6S+wlR+KrmGkEszpshB0Y1yL4yeuGg9rSmRusPhGO8Y7+EVTBDXRnoAlEeyfZsNJaVLY
vstpsKpNTEH2BRX+fcu4kxnN2lm6aupL486ucY5vy2zNfbn8ULsVsS82ZbCqMHKJwubdSxEc5Iui
2e/bWmuaUGBpM0+zT2/HrjMPCzQgiqyA3zJm/dkEZYdrosuJjZUFMVtuewIDAQABo4IB2zCCAdcw
CQYDVR0TBAIwADAdBgNVHQ4EFgQUbnYLe05PnOFgym0s6SeiopSzdzcwHwYDVR0jBBgwFoAU+lUN
jDRmUUNM9+ezp2yVr3rmpJcwCwYDVR0PBAQDAgbAMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMIMGMG
CCsGAQUFBwEBBFcwVTAqBggrBgEFBQcwAoYeaHR0cDovL3d3dy5mcmVldHNhLm9yZy90c2EuY3J0
MCcGCCsGAQUFBzABhhtodHRwOi8vd3d3LmZyZWV0c2Eub3JnOjI1NjAwNwYDVR0fBDAwLjAsoCqg
KIYmaHR0cDovL3d3dy5mcmVldHNhLm9yZy9jcmwvcm9vdF9jYS5jcmwwgcYGA1UdIASBvjCBuzCB
uAYBADCBsjAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5mcmVldHNhLm9yZy9mcmVldHNhX2Nwcy5o
dG1sMDIGCCsGAQUFBwIBFiZodHRwOi8vd3d3LmZyZWV0c2Eub3JnL2ZyZWV0c2FfY3BzLnBkZjBH
BggrBgEFBQcCAjA7GjlGcmVlVFNBIHRydXN0ZWQgdGltZXN0YW1waW5nIFNvZnR3YXJlIGFzIGEg
U2VydmljZSAoU2FhUykwDQYJKoZIhvcNAQENBQADggIBAKXJROLG+sChTZMKf9CgsXK0H8FIPD6V
fGiivNm5dk8alQFh/XJHLUGl7tJ3eGIDtUIiQPs6Js3hdgh7b7EBHfTMGeJXGqSgURCWZelMRvUL
0q3uasQTfiUbJaOdq9pFFRXY/54HIJ6Owgt4dPfhoO3nwAk3/oSjNPizJlztLY7Z32E5ZYNnf+s4
LB7jsj5upfBd8w3nufiQBdJSZvYS85yLT22rpte/usGWMrkGNzKfUqbwZqEOQ+qoH4SabF/j/ote
ojJ19ofyBS5QLqbDB2KmaMzgeHHdjpfjFbupKeJViZd6CjEs6WxRBrFDfHefKzYbGCiI8+6KI0N0
+gY+lWGSYn98QxBzll0SYJKOugCegDQprjJM+W8EI1Tze8pa/dx595NGqziL/HnwHcmGElTqbMEp
lBB2uD0gVW875RMmg38odveDOzcOfD1BBSOCfU9TQAxyIY11Ip/xDG+Ik6mjocDEK7TImME99Bx/
ZXO0/FZRWXGmEKew0oV8giWp+yBOrOyi6Jcaoa+HiGoq48cv4KCq6EKYCne+8WuSEVRYCQ2YK1lG
YDdk51oK09EUVLmYb2eLmrav6ElwM646v9TrQ7e8ne5ogVlJ5kgVgqgueFJ38ighB+/jkCAOBQis
uOqC6iUFJ288naKj07StOLv4hCvaNvwkSCkfVY3ALdHgMIIH/zCCBeegAwIBAgIJAMHphhYNqOmA
MA0GCSqGSIb3DQEBDQUAMIGVMREwDwYDVQQKEwhGcmVlIFRTQTEQMA4GA1UECxMHUm9vdCBDQTEY
MBYGA1UEAxMPd3d3LmZyZWV0c2Eub3JnMSIwIAYJKoZIhvcNAQkBFhNidXNpbGV6YXNAZ21haWwu
Y29tMRIwEAYDVQQHEwlXdWVyemJ1cmcxDzANBgNVBAgTBkJheWVybjELMAkGA1UEBhMCREUwHhcN
MTYwMzEzMDE1MjEzWhcNNDEwMzA3MDE1MjEzWjCBlTERMA8GA1UEChMIRnJlZSBUU0ExEDAOBgNV
BAsTB1Jvb3QgQ0ExGDAWBgNVBAMTD3d3dy5mcmVldHNhLm9yZzEiMCAGCSqGSIb3DQEJARYTYnVz
aWxlemFzQGdtYWlsLmNvbTESMBAGA1UEBxMJV3VlcnpidXJnMQ8wDQYDVQQIEwZCYXllcm4xCzAJ
BgNVBAYTAkRFMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAtgKODjAy8REQ2WTNqUud
AnjhlCrpE6qlmQfNppeTmVvZrH4zutn+NwTaHAGpjSGv4/WRpZ1wZ3BRZ5mPUBZyLgq0YrIfQ5Fx
0s/MRZPzc1r3lKWrMR9sAQx4mN4z11xFEO529L0dFJjPF9MD8Gpd2feWzGyptlelb+PqT+++fOa2
oY0+NaMM7l/xcNHPOaMz0/2olk0i22hbKeVhvokPCqhFhzsuhKsmq4Of/o+t6dI7sx5h0nPMm4gG
SRhfq+z6BTRgCrqQG2FOLoVFgt6iIm/BnNffUr7VDYd3zZmIwFOj/H3DKHoGik/xK3E82YA2ZulV
OFRW/zj4ApjPa5OFbpIkd0pmzxzdEcL479hSA9dFiyVmSxPtY5ze1P+BE9bMU1PScpRzw8MHFXxy
KqW13Qv7LWw4sbk3SciB7GACbQiVGzgkvXG6y85HOuvWNvC5GLSiyP9GlPB0V68tbxz4JVTRdw/X
n/XTFNzRBM3cq8lBOAVt/PAX5+uFcv1S9wFE8YjaBfWCP1jdBil+c4e+0tdywT2oJmYBBF/kEt1w
mGwMmHunNEuQNzh1FtJY54hbUfiWi38mASE7xMtMhfj/C4SvapiDN837gYaPfs8x3KZxbX7C3YAs
FnJinlwAUss1fdKar8Q/YVs7H/nU4c4Ixxxz4f67fcVqM2ITKentbCMCAwEAAaOCAk4wggJKMAwG
A1UdEwQFMAMBAf8wDgYDVR0PAQH/BAQDAgHGMB0GA1UdDgQWBBT6VQ2MNGZRQ0z357OnbJWveuak
lzCBygYDVR0jBIHCMIG/gBT6VQ2MNGZRQ0z357OnbJWveuakl6GBm6SBmDCBlTERMA8GA1UEChMI
RnJlZSBUU0ExEDAOBgNVBAsTB1Jvb3QgQ0ExGDAWBgNVBAMTD3d3dy5mcmVldHNhLm9yZzEiMCAG
CSqGSIb3DQEJARYTYnVzaWxlemFzQGdtYWlsLmNvbTESMBAGA1UEBxMJV3VlcnpidXJnMQ8wDQYD
VQQIEwZCYXllcm4xCzAJBgNVBAYTAkRFggkAwemGFg2o6YAwMwYDVR0fBCwwKjAooCagJIYiaHR0
cDovL3d3dy5mcmVldHNhLm9yZy9yb290X2NhLmNybDCBzwYDVR0gBIHHMIHEMIHBBgorBgEEAYHy
JAEBMIGyMDMGCCsGAQUFBwIBFidodHRwOi8vd3d3LmZyZWV0c2Eub3JnL2ZyZWV0c2FfY3BzLmh0
bWwwMgYIKwYBBQUHAgEWJmh0dHA6Ly93d3cuZnJlZXRzYS5vcmcvZnJlZXRzYV9jcHMucGRmMEcG
CCsGAQUFBwICMDsaOUZyZWVUU0EgdHJ1c3RlZCB0aW1lc3RhbXBpbmcgU29mdHdhcmUgYXMgYSBT
ZXJ2aWNlIChTYWFTKTA3BggrBgEFBQcBAQQrMCkwJwYIKwYBBQUHMAGGG2h0dHA6Ly93d3cuZnJl
ZXRzYS5vcmc6MjU2MDANBgkqhkiG9w0BAQ0FAAOCAgEAaK9+v5OFYu9M6ztYC+L69sw1omdyli89
lZAfpWMMh9CRmJhM6KBqM/ipwoLtnxyxGsbCPhcQjuTvzm+ylN6VwTMmIlVyVSLKYZcdSjt/eCUN
+41K7sD7GVmxZBAFILnBDmTGJmLkrU0KuuIpj8lI/E6Z6NnmuP2+RAQSHsfBQi6sssnXMo4HOW5g
tPO7gDrUpVXID++1P4XndkoKn7Svw5n0zS9fv1hxBcYIHPPQUze2u30bAQt0n0iIyRLzaWuhtpAt
d7ffwEbASgzB7E+NGF4tpV37e8KiA2xiGSRqT5ndu28fgpOY87gD3ArZDctZvvTCfHdAS5kEO3gn
GGeZEVLDmfEsv8TGJa3AljVa5E40IQDsUXpQLi8G+UC41DWZu8EVT4rnYaCw1VX7ShOR1PNCCvjb
8S8tfdudd9zhU3gEB0rxdeTy1tVbNLXW99y90xcwr1ZIDUwM/xQ/noO8FRhm0LoPC73Ef+J4ZBdr
vWwauF3zJe33d4ibxEcb8/pz5WzFkeixYM2nsHhqHsBKw7JPouKNXRnl5IAE1eFmqDyC7G/VT7OF
669xM6hbUt5G21JE4cNK6NNucS+fzg1JPX0+3VhsYZjj7D5uljRvQXrJ8iHgr/M6j2oLHvTAI2ML
dq2qjZFDOCXsxBxJpbmLGBx9ow6ZerlUxzws2AWv2pkxggOKMIIDhgIBATCBozCBlTERMA8GA1UE
ChMIRnJlZSBUU0ExEDAOBgNVBAsTB1Jvb3QgQ0ExGDAWBgNVBAMTD3d3dy5mcmVldHNhLm9yZzEi
MCAGCSqGSIb3DQEJARYTYnVzaWxlemFzQGdtYWlsLmNvbTESMBAGA1UEBxMJV3VlcnpidXJnMQ8w
DQYDVQQIEwZCYXllcm4xCzAJBgNVBAYTAkRFAgkAwemGFg2o6YIwDQYJYIZIAWUDBAIDBQCggbgw
GgYJKoZIhvcNAQkDMQ0GCyqGSIb3DQEJEAEEMBwGCSqGSIb3DQEJBTEPFw0yMjA2MjcwNjIwNDla
MCsGCyqGSIb3DQEJEAIMMRwwGjAYMBYEFJFto9hg7MqC40vFnReT5+loh18UME8GCSqGSIb3DQEJ
BDFCBEDZL8XoMygFn0kOt72wNF+2/UAA2kmywKi6LwvnFHuf0ZXGJelkA/hz10Ey83k1oIapBgkh
EuaX1lm5PsLZo9kCMA0GCSqGSIb3DQEBAQUABIICAHEbdm4Mdq4xX7YTSclIohAVZmoyaLNAs3zC
C6zisp+AQbtg+0m18dwGSDtGD2pOTenNYr540Zwed3pexk7BoYXP0vy5vlmDh8DqmvYFx9qW0dcC
teo/+PzezFow4mG4yZBS1z7gX+U0MHCNC4Wxf2Boe3+EPEzj+H3WXL8OzEwGPdP5+Mauv3h5jSEY
fGlyzWbl7n+lrEIs1m4ab5IlC7nstqes04EcRnFf2hwNwTh+OAQNvinUQURDutc9fXO9vamYFZHx
6DQkQwg/ML0+a5hb7IaKajDvsiqY/O0K684/7N2gjSBumMwuwtifvwR+oU2WNxfi9GFN1/tGeBcv
982xvegC9wgQIK5YCUAWvAyEsqMR474FbOy8ZtIo4u2EGucfhPw8CMdPUTbbOfA0/86j9vnnV3Nb
pbjVWuCUbEiErzWiRiCvwfKcCBnPEjj9sbZcamARxBztZ+0zypWEWe9Z7bLeGb1Y4f1z432zbKvu
dry0nogupDw96egAoFWKQ6BKJAzQkE+2ph1bBhVbOykuht0cw+6/En5fxsvI80RAVXp9hvzUdlgF
fYmTIp3U3uwCERFuCCux/qxc1+cAb4G8wK9sOHsPItMxmuo2Wdjz0Er77lJsFds8rU1YO6HRqn8m
6d5K3mTaVftOZ3jgDC/6Dd15ua2Vjp2xUa4qhYta</xades:EncapsulatedTimeStamp>
                        </xades:SignatureTimeStamp>
                    </xades:UnsignedSignatureProperties>
                </xades:UnsignedProperties>
            </xades:QualifyingProperties>
        </ds:Object>
</ds:Signature>
</receipt>

References

  1. ISO/IEC 29100:2011
    Information technology — Security techniques — Privacy framework
    https://www.iso.org/standard/45123.html

  2. ISO/IEC 29184:2020
    Information technology — Online privacy notices and consent
    https://www.iso.org/standard/70331.html

  3. ISO/IEC AWI TS 27560
    Privacy technologies — Consent record information structure
    https://www.iso.org/standard/80392.html

Last changed by 
 
lalchandran
28
1616

Read more

Legal PID Issuance

{'legalStatus': 'ACTIVE','legalForm': 'Aktiebolag','activity': 'Construction Industry','orgNumber': '559133-2720','registrationDate': '2005-10-18','registeredAddress': {'fullAddress': '123 Main St','thoroughFare': 'Sveavägen','postName': 'Stockholm','locatorDesignator': '111 34','code': '48','adminUnitLevel1': 'SE'},'attestationValidity': '31-Dec-2022'}

May 2, 2024
Organisation Digital Identity (ODI) use case during domain name validations

Data schema descriptions The following data schema is based on the work done for Proof of business PoC at Bolagsverket (Swedish Companies Registration Office) carried out together with Finnish and Norwegian counterparts. This is based on the nordic smart government [1] company registration data models. Field name Description Example Value legalStatus Legal status of the organisation ACTIVE

Oct 6, 2023
Analysis of usecases for combining SD-JWT and VCs

This is an attempt to anayse existing mecahnisms, e.g. EBSI and other implementations to understand the needs of combining SD-JWT with W3C VC for Type1 configurations. Questions being looked at are: Should we just use SD-JWT for Type1 issuer configurations? Is there a need to use W3C VC at all? Do we need a new spec for SD-JWT VC? What EBSI has done is they have embedded W3C-VC into the data field of JWT. This doesn&apos;t look like a standard spec. So when I as a holder request a credential, EBSI issues a credentials as JWT-VC. The issue here is SD wouldnt be possible, as far as I understand

Jun 20, 2023
Linking credentials with data exchange agreements through secured inclusive interfaces

On the need to link verifiable credentials with the right to use data in a secure, inclusive user interaction This short paper is the outcome of a collaborative project at the 11th Rebooting Web of Trust (RWOT) workshop from September 26 to 30, 2022, in Den Hague, Netherlands. Keywords Data Exchange Agreements (DEXA), Data Disclosure Agreements (DDA), Data Agreements (DA), Credential presentation, Accessibility features, Overlays Capture Architecture (OCA), Multi-jurisdiction use cases Authors Mr. Lal Chandran [LC] (iGrant.io, Sweden)

Dec 12, 2022
Read more from lalchandran
Published on HackMD