RFC - Entity Representation For Claims And Attestation

[gamemaker1]

I would like to propose the following representation for claims and attestations in the entity data model for consideration. This is an improvement over the Sunbird RC specification as given here. Some of the improvements are an adaptation of the W3C's verifiable credentials specification for entities in an electronic registry.

Suggested improvements include:

• All IDs are represented by URIs so that the specified object can be easily accessed by making a GET request on that URI.
• Claims are specified as a JSON object with the id and value properties.
• Attestations also include a signed JWT representation of the claims at the time of attestation, to ensure cryptographic verifiability.
• This data model can be extended by adding constructs such as consent artifact as specified in the Electronic Consent Specification.

---

RFC - Entity Representation For Claims And Attestation

Terminology

Registry

Any data store that stores and provides API endpoints to create, access, modify and delete data in accordance with this specification.

Entity

Any record stored in the registry.

Schema

A minimum representation of all entities of the same type.

Claim

An assertion made about an entity, which must be verified to be considered true.

Attestation

The process of evaluating a claim made about an entity, checking if it is indeed true, and then generating a cryptographically secure proof to declare it so.

Attestor

A role an entity might perform by receiving a representation of an entity and putting its claims through the process of attestation, if it is designated as attestor for a certain claim made by another entity.

Representation

A student entity might be represented as follows:

{
	"context": {
		"baseUrl": "https://example.com/registry/",
		"schemas": ["https://registries/schemas/entity.json"]
	},
	"id": "https://example.com/registry/api/student/GcivYPrwdeIOREu4UqCpO854",
	"kind": "https://example.com/registry/api/student",
	"claims": [
		{
			"id": "https://example.com/registry/api/student/GcivYPrwdeIOREu4UqCpO854/name",
			"value": "Pranav Agate"
		},
		{
			"id": "https://example.com/registry/api/student/GcivYPrwdeIOREu4UqCpO854/phoneNumber",
			"value": {
				"country": "IN",
				"number": 9988776655
			}
		},
		{
			"id": "https://example.com/registry/api/student/GcivYPrwdeIOREu4UqCpO854/class",
			"value": 10
		},
		{
			"id": "https://example.com/registry/api/student/GcivYPrwdeIOREu4UqCpO854/school",
			"value": "UP Public School"
		}
	],
	"attestations": [
		{
			"attestor": "https://example.com/registry/api/teacher/RBFrXEOG890jZBUf1Vpuy",
			"date": "2021-10-08T19:37:03+1200",
			"claims": [
				"https://example.com/registry/api/student/GcivYPrwdeIOREu4UqCpO854/school"
			],
			"signature": {
				"type": "https://registries/signature-types/jws-rsa256",
				"keyId": "https://example.com/registry/meta/signing-keys/IL5JLA2MinN9vVLFUxiLR",
				"value": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJjb250ZXh0Ijp7ImJhc...mZG8GbRlzpUkAEPI1vkhGc"
			}
		}
	],
	"metadata": {
		"created": "2021-10-07T16:52:32+0530",
		"lastUpdated": "2021-10-08T19:37:03+1200"
	}
}

Following is a line-by-line breakdown of the entity representation above:

"context": {
	"baseUrl": "https://example.com/registry/",
	"schemas": [
		"https://registries/schemas/entity.json"
	]
}

The baseUrl property tells the client parsing this JSON representation that the API path actually starts after this point in the URL. The schemas field can be used to extend the representation by adding more fields to it.

"id": "https://example.com/registry/api/student/GcivYPrwdeIOREu4UqCpO854",
"kind": "https://example.com/registry/api/student"

The id field is a direct URL to the entity. If you make a GET call to the URL, it should return exactly this representation of the entity. The kind field gives us a URL to the schema of the entity.

"claims": [...]

Each claim is represented by a JSON object as follows:

{
	"id": "https://example.com/registry/api/student/GcivYPrwdeIOREu4UqCpO854/class",
	"value": 10
},

In this case, the claim is class, the value is 10.

The attestationPolicy for a claim can be mentioned in the schema as follows:

"attestationPolicy": {
	"attestorKind": "https://example.com/registry/api/teacher",
	"condition": "{ATTESTOR}.school == {ENTITY}.school"
}

In this case, the claim can be attested only by a teacher entity that is in the same school as the student. When evaluating the condition, the field's value must be attested, else it will be considered null.

"attestations": [...]

Each attestation is represented as follows:

{
	"attestor": "https://example.com/registry/api/teacher/RBFrXEOG890jZBUf1Vpuy",
	"date": "2021-10-08T19:37:03+1200",
	"claims": [
		"https://example.com/registry/api/student/GcivYPrwdeIOREu4UqCpO854/school"
	],
	"signature": {
		"type": "https://registries/signature-types/jws-rsa256",
		"keyId": "https://example.com/registry/meta/signing-keys/IL5JLA2MinN9vVLFUxiLR",
		"value": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJjb250ZXh0Ijp7ImJhc...mZG8GbRlzpUkAEPI1vkhGc"
	}
}

In this case, the attestor is a teacher entity. The attestation of the school claim took place on 2021-10-08T19:37:03+1200 and the cryptographic proof is attached as the signature object.

"signature": {
	"type": "https://registries/signature-types/jws-rsa256",
	"keyId": "https://example.com/registry/meta/signing-keys/IL5JLA2MinN9vVLFUxiLR",
	"value": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJjb250ZXh0Ijp7ImJhc...mZG8GbRlzpUkAEPI1vkhGc"
}

In this case, the claims have been signed using an RSA private key whose ID is IL5JLA2MinN9vVLFUxiLR. The claims object of the entity representation at the time of attesting is taken as the payload of the JWT, signed by a private key by the registry, and appened to the attestations array.

[pramodkvarma]

I think we need to differentiate "electronic registry" aspects with VCs slightly. They are not the same. Registry stores the profile of the actors which contains many VCs (linked). Of course profile itself can be seen as an identity credential, but, it is important that we carefully distinguish them and make it "linked VCs" to ensure actor can selectively make claims using portions of the registry.

I suggest we use the Google doc created by Rahul Kulkarni to bring it all together.

[bharatkashyap]

1. Agree with the above on the need to have "registries" and "credentials" independent yet linked. Here, this would translate to the attestations array on the entity containing only a list of URIs of the VCs along with their respective claim IDs.

"attestations": [
		{
			"uri": "https://example.com/registry/api/credential/RBFrXEOG890jZBUf1Vpuy",
			"claims": [ 
			"https://example.com/registry/api/student/claim/GcivYPrwdeIOREu4UqCpO854/",
			"https://example.com/registry/api/student/claim/GcivYPrwdeIOREu4UqCpO834/",
			]
		}
	]

2. Also important to separate the notion of "claims" and "attributes": attributes contain the profile information of the entity, whereas the claims may be made on these attributes. A list of claims, then, should become an attribute-log, traceable to the first "claim", which may be a "self-attestable" initial claim on the attributes.

3. The notion of "consent" then fits into this model as being a "claim" on the ability to modify these attributes, and the consent artefact is the linked credential generated upon attestation of this request.

@gamemaker1

[rahul101001000]

Agree on credentials.

How attributes get stored in the schema may be an implementation detail. What should be stored as part of the attributes is something the spec should call out. I've incorporated the clarity that @gamemaker1 provided in his RFC into the first point (Nouns) under section 6 of the Draft Technical Spec Google Doc. Please do review and comment.

@gamemaker1 @pramodkvarma @bharatkashyap @dileepbapat @tejash-jl