Schema Configuration
Schema
All registries have attributes pertaining to the entity or the fact in question either person or things. Schema defines the structure and constraints of the entity, open saber rc uses standard JSON-LD based schema.
In the example given below Place is Concept that registry is storing supporting name, city, addressRegion (state) and country.
Example:
Configuration
In addition to JSON LD specific data types SunbirdRC supports various extension configurations under “_osConfig”. Access, indexing, primary key etc are configurable using schema configuration.
Entity and Properties
Property data types and restrictions
Supported types:
String - Unicode text, additional regular expressions restrictions can be applied.
Enum - restricted list of values
Number - numeric data
Integer - The integer type is used for integral numbers
Object - Objects are the mapping type in JSON. They map “keys” to “values”. In JSON, the “keys” must always be strings. Each of these pairs is conventionally referred to as a “property”.
Array - Arrays are used for ordered elements. In JSON, each element in an array may be of a different type.
Boolean - The boolean type matches only two special values: true and false. Note that values that evaluate to true or false, such as 1 and 0, are not accepted by the schema.
More details are available here Type-specific keywords.
List of attributes
Collection of data values are also supported as multiple data value might represent the entity property for example subjects taught : [“english”,”science”, “mathematics”]
Visibility scope:
3 types of visibility on attributes.
Public
Private (privateFields)
Internal
Public data attributes are available in discovery by default any sort of permission / authorization is not needed by default. By default all fields are public.
Private attributes can be accessed by the owner by default, with consent 3rd party can access the data field.
Internal fields are system fields that only serve internal functionalities, these can never be accessed by any actors in the system.
System fields:
The following property is used to add additional audit fields to entity, to know who/when created/updated the entity.
osCreatedAt
osUpdatedAt
osCreatedBy
osUpdatedBy
Index field set
Indexes can help in faster access to information, based on usage context index fields can be configured. Example:
"indexFields": ["phoneNumber"],
Primary Keys for Entities
Primary keys from domain space will help enforce uniqueness of information and make it easily accessible. “uniqueIndexFields” can be used to configure the same.
Example:
"uniqueIndexFields": ["identityProperty"]
Validation Extensions
JSON LD schema allows defining basic type constraints like numeric type, text or list of items etc. Also it allows a list of possible values for given attributes (enum) and regular expressions based constraints for the value.
Roles
Manage registry based on roles
Using roles
config, one can set the authorization for crud operations on the schema
Example: let's say there are two registries Teacher and EducationCertificate, assume only Teacher can manage (add/update/delete) the EducationCertificate, then assign role "teacher" to the relevant user in a keycloak and add the "roles" : ["teacher"] in the EducationCertificate config, now only token which has the role "teacher" can manage the EducationCertificate
Invite based on roles
Using inviteRoles
config, one can set the authorization for invite operation
Example:
1. Only teacher can invite student
Let's say there are two registries Teacher and Student, assume only Teacher can invite the Student, then assign role "teacher" to the relevant user in a keycloack and add the "inviteRoles" : ["teacher"] in the Student schema config, now only token which has the role "teacher" can invite the Student.
2. Anyone can invite student
Set "inviteRoles" : ["anonymous"] in Student schema config, now anyone can invite the Student
Anonymous role: Any of the above role configs can be set to anonymous to allow anonymous access to the respective operations
Create login for registry
By default login is disabled for the registry, we need to set enableLogin:true
inorder to create the user in keycloak. Login credentials for an entity can be configured through ownershipAttributes
attributes. This attributes contains a list of objects for which a user enitity in keycloak will be created.
We can have more than one owner for an entity. The respective json paths for the fields needs to be configured. All the properties are mandatory for creating an owner.
Attestation policy
List of policies can be configured for the attestation.
Attestation Policy Attributes:
name
A unique name for identifying an attestation policy. This name will be used to refer an attestation policy while raising a claim.
attestationProperties
This field refers the schema properties which will be considered for attestation.
additionalInput
This denotes the additional inputs that needs to be captured outside the existing entity/schema fields for generating/processing the attestation.
type
This denotes if the attestation should be raised manually or automatically.
MANUAL: In this two types of user will come into the picture, i.e Attestor and Requestor, Requestor will rise a claim, and the Attestor will approve/reject. The authorization of the attestor will be defined in the config using
conditions
attribute.
Example: Only teacher from the particular institute can attest the student,
For this scenario the condition would be, conditions: "(ATTESTOR#$.experience.[*].instituteOSID#.contains(REQUESTER#$.instituteOSID#))"
The above snippet says that attestor's education institute and requestor's experience must belong to the same institute.
AUTOMATED: If the attestation policy is
AUTOMATED
then a claim will be initiated automatically without any user intervention/API calls. When there is any addition/modification to theattestationProperties
then the matching attestation policy will be triggered and executed.
attestorPlugin
This denotes who processes the claims that is been raised by the user. By default SunbirdRC will be shipped with a ClaimPluginActor
who will process and store the respective claims in DB. If we need additional or different functionalities then we can
Credential Template
This property holds the template to be used for generating the VC. It needs to be a template that follows W3C standards. It can be an url or the template object can be defined inline. The signed data (VC) generated by this template will be used to generate a QR Code.
Ex: inline:
Ex: external url
Certificate Template
This property holds the template to be used for generating visual certificate. The key can be used while downloading the certificate.
Last updated