SSI lifecycle
Introduction
In order to establish the relation between two entities, an individual and business or business to business a set of agreements need to be set which dictates how data is processed. The below diagram describes the key components in that relation.
Agreement
An agreement describes the purpose of collecting and using personal data. The agreement follows the regulation required to inform the individual like GDPR. Note there may be multiple purposes for collecting same source of data. More is described under Agreement Types
Personal data
Any personal information relating to the individual which are bound by the agreement. Information may be a snapshot captured on a form or a continous stream of data like a activity monitoring in a smart watch.
Assessment
There are several types of assessment that can be performed to ensure compliance to standards or GDPR. Regulation may require HIPAA compliance when handling health information or ISO 27001 compliance for information security systems. For highlight sensitive personal data a Data Protection Impacts Assessment (DPIA) is performed to identify and mitigate any risks. The result of an assessment hase same lifecycle as an agreement and will not be described in more detail.
Trust over IP - Semnatics WG is standardizing the data capture of personal data.
Agreement types
The following diagram is an overview of the different Agreement Types (or Notice Receipts as specified in Kantara). Depending on the nature of the collected data there are legal requirements to share the data either for public good, vital interest (necessary to protect someone's life) or legal obligations. The legimtimate interest agreement is the basis for defining purpose and there are different types of consent associated to the baes. For example an opt-in consent would have type "explicit consent agreement". For more convenience a "general consent agreement" allows a generic opt-in consent so it is not necessary to request new consent every time. The contractual agreement is necessary if taking steps prior to entering an agreement.
The list of agreement types are being developed in association with Kantara as a future iteration of the Kantara Consent Receipt Specification v1.1.
Building an agreement
An agreement may serve more than one purpose. While a privacy policy or terms of service may be a single document or a webpage, it is important to note that each purpose will have its own verifiable credential which may have different data processing conditions, data limitation or expiration. An opt-in consent would have its own verifiable credential. For example in the below diagram an explicit consent agreement can be withdrawn at any stage while the legitimate interest and initial consent has an expire of 1 year while for legal purposes for example information may be kept for 7 years.
Preparing
The following process is an overview of the steps needed to create the verifiable credentials (VC) in step III and subsequently perform a proof request against the new VC.
Step I: A specification is created that defines what information needs to be captured to satisfy regulatory bodies (country level Data Protection Authority), standards body (Kantara) or industry consortium (GA4GH). For example the Kantara Consent Notice is an example of the specification.
Step II: Once a specification is available the organisations (Issuer in DLT terms) need to prepare the information required to be included in the step III, agreement/form capture. Preparation may include adding mandatory information, providing default values or preparing the normalisation of the capture if not already defined in the specification.
Step III: In stage III the Issuer can present to the individual (Holder in DLT terms) the agreement and form. When the individual has accepted the conditions of the agreement and populated the form one or more verifiable credentials can be created.
Step IV: The verifiable credential can then be used as proof towards any verifier that requires to check a claim.
Withdrawing
Prior to a verfiable credential expiring there are two methods of withdrawing the verifiable credential, one is more secure. Either deleting the verifiable credential from the wallet of the Holder and Issuer or revoking the credential. Revoking the credential is the most secure since it ensures that when a "Verifier" checks if the verifiable credential is still valid and has not been revoked.
Updating
Updating of an agreement, private data or assessment would require creating a new verifiable credential. Depending on the nature of the update the previous verifiable credential is revoked.