Concept of Consent for Verifiable Credentials in Sunbird RC

[ChakshuGautam]

Problem Statement

TL;DR - I am not aware of a credential level consent which is a requirement in some use cases. Please point me to the implementation if this is already available and please skip the rest; if no, please proceed.

Details

Given that Credentials are an artifact of verified data, they are owned either by the Holder or the Subject and are generally shared with consent on request by a Verifier in a 1:1 communication. Given that this problem statement is pretty generic and can be stated as someone sharing any form of data with consent, there is any number of ways this can be implemented.

Sunbird RC currently has an opinionated way to do this. RC should expose a more generic way to express this consent (of Holder or Subject) and how it is coupled with their owned credentials. This implementation should be independent of how that consent is evaluated or modeled.

Proposed Solution

The current graph-based modeling of the Verifiable Credentials Data Model couples that consent with the data model and provides consent at a field level for attestation. This is not the same as sharing a VC by a subject with a verifier.

The following are recommended

1. Given that VC data can not be currently hidden when shared, RC should split the specifications of the VC Data Model from the consent of sharing the VC. An example implementation - A request for VC from a verifier for a subject should be authenticated by a one-time use token shared by a holder/subject.
2. This consent of sharing solely remains with the Subject/Holder and implements this as a first-class citizen in Sunbird RC and should not be delegated because the subject is verified when sharing. Similarly, the revoke access remains solely with the Issuer - given that no other person can identify as an issuer.
3. Programmatic sharing (by delegation) is not how physical credentials are shared.

cc:- @rahul101001000 @parthlawate @coolbung @suresh12

[sankarshanmukhopadhyay]

Given that Credentials are an artifact of verified data, they are owned either by the Holder or the Subject and are generally shared with consent on request by a Verifier in a 1:1 communication. Given that this problem statement is pretty generic and can be stated as someone sharing any form of data with consent, there is any number of ways this can be implemented.

A holder (not always the data subject/principal because of delegation/guardianship) of a VC would be able to manage and undertake various aspects of control (e.g. choosing to share fully, partially or not at all). The "ownership" is still with the issuer in the context of governance in a digital trust ecosystem. There are certain additional concerns when thinking about ownership because the term brings in the rights associated with property - that's for a separate discussion.

To test this consider two different verifiable credentials such as a passport (or a driver's license) and a graduation certificate. The recipient is not the owner - they are in receipt of these and the possession enables them to do additional aspects of flows.

Would the framework provided by DEPA be also sufficient to cover all credentials issued within a specific trust ecosystem? With additional notice/consent being logged per transaction? I understand that is what you are proposing as a solution.

[ChakshuGautam]

Thanks, @sankarshanmukhopadhyay for this review. Agreed on the ownership part - was not correct to define the data being owned by the subject holder. Issuer is the owner of VC in terms of governance. I think the terms Holder and Subject are very aptly chosen by W3C.

Given that currently, VCs don't allow for partial sharing of data currently - should this be modeled as a binary consent to share or not at a VC level? I think DEPA would be perfect for this use case if partial sharing is allowed!!

TL;DR
Issuer - Governs (issues, revokes)
Subject - Claims, Shares (partially, fully or not at all)

[ChakshuGautam]

There are certain additional concerns when thinking about ownership because the term brings in the rights associated with property - that's for a separate discussion.

Let me ping you for how we can model ownership in the right way because without that it would not be wise to build a downstream consent.

[parthlawate]

A. Aligning Consent for Verifiable Credentials with the Meity Framework

Sharing the MeitY Consent tech framework document

https://dla.gov.in/sites/default/files/pdf/MeitY-Consent-Tech-Framework%20v1.1.pdf

It defines various entities in this context which we should also map these to the VC Constructs so we can also validate to this spec.

For instance Data Consumer/Consent Collector in this context would be the Verifier

Data Provider would be the Issuer ?

3.1. Data — Any electronic information that is held by a public or private service
provider (like a government service department, a bank, a document
repository, etc). This may include both static documents and transactional
documents.
3.2. User — any person or entity who wishes to share data about them for availing
a service.
3.3. Data Provider (DP) — Any entity which has data about users in their system
that can either be given to the user (whose data it is) or to another entity based
on the consented request of the user.
3.4. Data Consumer (DC) — Any entity which accesses data for providing a
service to the user.
3.5. Consent Collector (CC) — An entity that interacts with users and obtains
consent from them for any intended access to data. This role may be played by
the Data Consumer

===
B. Not directly related to the discussion -- but even the Registry part of RC handles Data Consents in the respect of Claims. When you make a claim, you provide some data & are allowed to provide more data on request with consent.

We should also align that to comply with the framework if not already.

cc @tejash-jl

[rahul101001000]

B is important.. RC should not deal with consents, that should be done via consent manager sitting outside RC.

This is the open source consent manager implementation for health that can be used external to RC for enabling consent.
https://github.com/projectEKA

Also relevant may the HIE-CM Spec 
https://github.com/iSPIRT/healthstack

[ChakshuGautam]

I was looking into Open Policy Agent and I feel the flat hierarchy (instead of the graph) can very well be implemented through it. Please let me know your thoughts on the same.

[sukhpreetssekhon]

@tejash-jl @Renuka-S - Given the updated thinking on the next version of Sunbird RC APIs (Identify, Credential, Schema), please can you share if Open Policy Agent can be used as a role resolver for Sunbird RC.

If not, then would be great to understand why.

[tejash-jl]

@sukhpreetsamagra Yes this could help us map more finer roles to users/entities. Since our core services are in Java, we can explore WASM integration or even through APIs.

[sukhpreetssekhon]

@snehal0904

[surendrasinghs]

Have we evaluated the potential impact of this in terms of - complexity of the solution stack, skills required to use/configure, and so on. I am generally wary of adding too many tools/frameworks to solution as that will have direct impact on the 'ability to adopt'.

If we are expecting the reference solution to be used by/in government institutions, we should evaluate our choices from that lens.

I am not well-versed with OPA to offer a conclusive remark. Requesting @coolbung @ChakshuGautam @dileepbapat @tejash-jl to weigh-in and help arrive at a decision.