owned this note
owned this note
Published
Linked with GitHub
# Consent Receipts as Delegatable, Verifiable Credentials
## Purpose of this document
Demonstrate how data consent receipts can be encoded as self-contained, W3C-compliant [Delegatable Verifiable Credentials](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0104-delegatable-credentials/README.md) and used to limit access to protected resources within Proxy Trust Frameworks that keep the Data Subject in the locus of control.
## Motivation
In the online world, individuals frequently consent to a service provider gaining access their protected resources located on a different service provider. Individuals are challenged with an authentication mechanism, informed of the resources being requested, consent to the use of their resources, and can later modify the access scope or revoke it at any time. [Google's Sign-in](https://developers.google.com/identity/sign-in/web/sign-in) feature is a good example of this.
Most efforts in Hyperledger Aries (and prior to that, Hyperledger Indy) focused on the simplest forms of resource sharing where the Data Subject is also the Holder of their own resources, leaving out numerous use cases where that is not the case. Specifications and guidance on how to encode and govern Trust Frameworks or Trusted Contexts was lacking.
Recently, the [Indirect Identity Control](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0103-indirect-identity-control/README.md) RFC layed out the basics of a framework in which these other scenarios can function. *Proxy Trust Frameworks* were introduced that define jurisdictional constraints, codes of conduct for all parties involved, permissions granted to the proxy, and mechanisms for auditing and appeals. It introduced three variants of indirect identity control of which **delegation** is of particular interest in this document.
More recently, the [Delegatable Credentials](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0104-delegatable-credentials/README.md) RFC provided more specific encoding rules for representing certain aspects of delegation. Crucially, they support the binding these credentials to their holder and the encoding of proof of the delegator's authority to delegate, both important requirements in Proxy Trust Frameworks with tight audit and security requirements. Another practical benefit of using deletagable credentials is that only their root Issuer is burdened with the setup, tooling, and maintenance required for issuance and revocation of root credentials.
## Tutorial
The relation between a Resource Server, Resource Owner (Data Subject), and the Requesting Party can be modelled as a cascading chain of delegation that begins with the Resource Server identifying the Resource Owner as its *delegate* for a certain subset of resources and grants them certain permissions over those resources. In turn, the Resource Owner further delegates unto the Requesting Party certain permissions over a subset of that subset. When the Requesting Party approaches the Resource Server it does so acting as the Resource Owner's delegate, who in turn is a delegate of the Resource Server itself.
Let's use the example of Alice, an accomplished individual who has completed several courses and earned several certifications at *Mooc-cred*, a Massive Open Online Courses provider. Alice is also a registered user of *Online-Pros*, a professional networking website where members can published their accredited accomplishments. Alice wants to add her latest certification "Cryptography I" from *Mooc-cred* to her profile on *Online-Pros*. Mooc-cred offers a form of data-sharing framework that gives its members fine grained control over their data. Since Mooc-cred is a very popular MOOC, many professional networking sites support this framework, including Online-Pros.
Alice accepted Mooc-cred's privacy terms when she first signed up for an account. That process resulted in Mooc-cred issuing a consent receipt in the form of a credential making Alice Mooc-cred's delegate over a subset of resources served by Mooc-cred - in this case, Alice's basic profile data as well as her courses, grades, and certifications. She was also given access to Mooc-cred's revocation registry so that she can revoke credentials that she delegates at any time:
![image](https://i.imgur.com/Xlhhcuu.png)
As Mooc-cred's delegate in the role of Resource Owner, Alice has control over a set of resources hosted on Mooc-cred's servers and can prove it with her credential. Just proving she has the authority is not very useful in itself, but providing a third party with the means to prove they possess the authority to perform some operations on a portion of those resources is valuable. So she further delegates unto Online-Pros the authority to *read* her credential of type *certification* with name *Cryptography I*:
![image](https://i.imgur.com/a48M2Bc.png)
As Alice's delegate with authority to read her Cryptography I credential, Online-Pros can independently approach Mooc-cred, present proof of this credential and, providing all conditions encoded in the credential are satisfied at this point in time, can access Alice's credential and display it on Alice's profile on their website:
![image](https://i.imgur.com/8uaSbQC.png)
### Differences vs. OAuth2
The Resource Owner and the Authorization Server have been collapsed into one - the Data Subject (end-user). This is made possible by the fact that none of the [problems](https://tools.ietf.org/html/rfc6749#section-1) that OAuth2 aimed to solve apply in a Proxy Trust Framework that keeps the Data Subject in the locus of control:
* The Requesting Party does not impersonate the Data Subject.
* The Requesting Party is never given overly broad access to the protected resources - their access scope is defined by the Data Subject with arbitrary granularity.
* The Data Subject can revoke access to a single Requesting Party without affecting others. The Data Subject merely has to revoke the delegated credential held by the specific Requesting Party.
## Reference
### Root Consent Receipt
The root consent receipt is offered and issued by the Data Controller to the Data Subject via the [Issue-Credential](https://github.com/hyperledger/aries-rfcs/blob/master/features/0036-issue-credential/README.md) protocol.
Using the Decentralized Identity Interoperability Project's [representation](https://github.com/decentralized-identity/interoperability/issues/5#issuecomment-516794494) for VCs as JWS, the credential could look like this:
```jsonld=
{
"alg": "EdDSA",
"typ": "JWT",
"kid": "did:example:mooc-cred#key-1"
}
{
"iss": "did:example:mooc-cred",
"sub": "did:peer:alice",
"aud": "did:peer:alice",
"jti": "moocred-to-alice",
"iat": 1541493724,
"nbf": 1541493724,
"exp": 1573029723,
"nonce": "...",
"vc": {
"@context": [
"https://w3.org/2018/credentials/v1",
"https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0104-delegatable-credentials"
],
"type": ["VerifiableCredential", "Proxy.D/mooc-cred/1.0/user-consent"],
"schema": "base64(schema)",
"delegationProof": {
// proof that Alice accepted the terms of privacy
},
"credentialSubject": {
"proxied": {
"type": "urn://mooc-cred/schemas/consent-receipt#proxy",
"permissions": {
"grant": ["read", "write", "delegate"],
"when": {"role": "resource-owner"},
"scope": {
"urn://mooc-cred/schemas/courses": ["*"],
"urn://mooc-cred/schemas/degrees": ["*"],
"urn://mooc-cred/schemas/user-profile": ["*"]
}
}
},
"holder": {
"type": "urn://mooc-cred/schemas/consent-receipt#resource-owner",
"role": "resource-owner"
}
}
}
}
```
### Delegation to Requesting Party
The delegated credential issued by the Data Subject to the Requesting Party could look like this:
```jsonld=
{
"alg": "EdDSA",
"typ": "JWT",
"kid": "did:peer:alice#key-1"
}
{
"iss": "did:peer:alice",
"sub": "did:peer:alice",
"aud": "did:example:online-pros",
"jti": "alice-to-onlinepros",
"iat": 1541493724,
"nbf": 1541493724,
"exp": 1573029723,
"nonce": "...",
"vc": {
"@context": [
"https://w3.org/2018/credentials/v1",
"https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0104-delegatable-credentials"
],
"type": ["VerifiableCredential", "Proxy.D/mooc-cred/1.0/user-consent"],
"schema": "base64(schema)",
"delegationProof": {
"jws": "compactJWS(moocred-to-alice)"
},
"credentialSubject": {
"proxied": {
"type": "urn://mooc-cred/schemas/consent-receipt#proxy",
"permissions": {
"grant": ["read"],
"when": {"role": "requesting-party"},
"scope": {
"urn://mooc-cred/schemas/degrees": [{
"op": "=", "name": "Cryptography I"
}]
}
}
},
"holder": {
"type": "urn://mooc-cred/schemas/consent-receipt#requesting-party",
"role": "requesting-party"
}
}
}
}
```
### Requesting Party presents proof of consent to Resource Controller
The Requesting Party proves to the Data Controller that the Data Subject has consented to their use of their data:
```jsonld=
{
"alg": "EdDSA",
"typ": "JWT",
"kid": "did:example:online-pros#key-1"
}
{
"iss": "did:example:online-pros",
"sub": "did:peer:alice",
"aud": "did:example:mooc-cred",
"jti": "onlinepros-to-mooccred",
"nbf": 1541493724,
"iat": 1541493724,
"exp": 1573029723,
"nonce": "...",
"vp": {
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0104-delegatable-credentials"
],
"type": ["VerifiablePresentation", "Proxy.D/mooc-cred/1.0/user-consent"],
"verifiableCredential": ["compactJWS(alice-to-onlinepros)"]
}
}
```
### Modifying scope of the Requesting Party's authority
> **TODO**
### Revocation
> **TODO**
## Prior Art
### Data Consent Lifecycle RFC
The [Data Consent Lifecycle RFC](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0167-data-consent-lifecycle/README.md) models data consent receipts as regular [Verifiable Credentials](https://w3c.github.io/vc-data-model/) that are issued by the Data Controller to the Data Subject. The Data Subject is then tasked with proving they have been issued this data consent receipt to the requesting party. We see a few problems with this approach:
* The Data Subject lacks the means and authority to revoke the consent receipt credential.
* The Requesting Party is not linked to the proof. It is strongly recommended to link the data consent receipt to its holder within a [Trust Framework](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0103-indirect-identity-control/README.md#proxy-trust-framework). This poses a security risk as well as complicates the audit trail.
* Expensive tooling and maintenance is required to issue normal Verifiable Credentials.
## Others (non-Aries)
The following are existing standards currently not compatible with Aries specifications:
**User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization**
IETF RFC: https://tools.ietf.org/html/draft-maler-oauth-umagrant-00
**The OAuth 2.0 Authorization Framework**
IETF RFC: https://tools.ietf.org/html/rfc6749
**OpenID Connect**
Specs: https://openid.net/connect/