SSI and Guardianship - What's Next? The Assurance Community

* whitepaper “On Guardianship in Self-Sovereign Identity.”

Recall how a guardianship credential is used in an arbitrary application and let us assume that the application knows its user through (traditional or SSI-related) login means. The application must then find out what the user is allowed to do because of its rights or duties as it fulfills a specific guardianship role in an arrangement where some other person is the dependent. That can be a lot to figure out. But the real difficulty is that when the syntax and/or semantics change, roles and rights are structurally added or removed from such credentials, then the application code needs to be adapted to accommodate for such changes.

This is cumbersome, but we should realize that organizations currently also need to do this, and also struggle with these compliance questions. They need an inventory of laws/regulations that they and their systems must comply with. The organizations need people who keep track of changes, people who determine the impact on the organizations' systems, people who write change requests (project proposals) that ensure that the various systems are 'updated' to comply with these changes, and people who allow responsible managers to allocate budgets. Then, projects have to be defined, a project team needs to be formed, the project has to be done, the results tested and only then can the updated application go live. For larger companies this may easily take 3-6 months, and chances are that the rules to comply with will have changed again in the meantime.

At first, it may seem like this is a simple 'translation problem', that can be solved in several ways. The translation problem is to find an answer to the question "how can my application X decide/accommodate requests from a given user for which (s)he has a (legal) right or duty under some guardianship arrangement?". It is about 'translating' (legal) rights and duties to permissions in a computer system.

However, most of this 'translation' is work for humans with different backgrounds are required to get the full picture. A lawyer would know how to interpret rights and duties but may not have a clue regarding the permissions that applications work with. Conversely, the owners of business processes (and business applications) would know about such permissions yet may lack the required knowledge about the (legal) details of the meaning of rights and duties in order to effectuate them in all circumstances in the application.

The problem might be solved if these different people sat together, and if we had them create the following mechanisms, for which they are responsible as a group:

• Set of specifications for 'permission-credentials': credentials that contain permissions (for the credential holder) for generic actions in the organization. An example would be a credential that provides its holder with the permission to access a selected set of bank accounts of someone else. But there would be many more generic actions - as many as there are functions that an IT system could provide and that a user might have the right to access if (s)he was acting on behalf of someone else.
• 'Translation' mechanism: a means by which guardianship rights and duties can be translated into any such credentials, as (legally) appropriate. For example, if a guardianship credential states that a certain person fulfills the role of 'inheritance-executor' on behalf of the person that fulfills the role of 'deceased', that would translate into a permission credential where the first person is the subject, and access-rights for bank accounts (which were held by the deceased) are the rights mentioned in the guardianship credential. While the derivation of permission credentials from guardianship credentials is not likely to be fully automated, it also need not be a fully manual activity.
• 'Issuing' mechanism: a means by which the results of translation, i.e., various permission-credentials that are derived from an individual guardianship credential, are provided with assurances (specifically of course the signature) that allows the IT of organizations that use them to accept them as valid, trustworthy statements, without further scrutiny - as if someone in the organization itself had issued these permissions. The issuing mechanism should make use of clear protocols and procedures, to allow other parties to rely on the trustworthiness.

Such a committee could obsolete large parts of the cumbersome trajectory of coping with changes in rules and regulations. For organizations, (co-)owning permission-credential specifications ensures that such credentials are not only actually used in applications, but the specifications remain stable for a long time—much longer than the rules and regulations that they seek to accommodate. Changes in IT systems would only be called for if the specification changes—not when the laws change. This might constitute considerable savings.

Of course, the translation and issuing mechanism would still need to be operationalized: whenever a guardianship credential is issued, it needs to be properly 'translated' into several different permission credentials that enable its owner to exercise its rights under the guardianship. Many organizations (e.g., banks) devise working instructions that its staff uses to ask the user for various documents, validate these documents and ultimately decide about the rights to grant to the user. Such working instructions are typically much easier to adapt than IT systems, and it can be done in the same pace as the regulatory changes. To accommodate for guardianship credentials and permission credentials at this level does not seem to be a big deal. And the ability of staff to deal with a guardianship credential might make it easier for users to provide the necessary data that they might otherwise need to provide from various documents.

The ability to also issue permission credentials to the user might enable him to use them in multiple organizations. For example, a 'translation officer' could issue the right to access a bank account of a deceased for every bank account established to be owned by the deceased. Such a credential is not necessarily restricted to the bank at which the officer works. But, of course, it will only be trusted by bank (systems) if signed by, or on behalf of a trustworthy organization.

All this is a nice fit for what is being proposed as an SSI Assurance Community this is a community of organizations that already exist, already work together, have established ways to deciding on (not) trusting one another, etc. For example, banks have communities in which they work together to realize benefits for them all in areas where they do not compete. An example might be a community in which they arrange for cross-bank payments, or for sharing their KYC burdens. Such communities could take ownership of 'banking-permission-credentials'. The banks might consider joining forces with notaries or other trustworthy organizations that already have dealings with people under guardianship conditions and by their trade know what these various guardianships entail. It should be a relatively small step to dive deeper into the various banking-permission-credentials, what they mean, and find out how to create these banking-permission-credentials based on the various guardianship credentials or other legal, verdict-like credentials that specify rights and duties. This might be something to look further into. To be continued...?

Sterre den Breeijen, Rieks Joosten, Peter Langenkamp (TNO)
Leon Roseleur (KNB)

Read more blogs about SSI and guardianship

This blog is the third in a series of three blogs about SSI and guardianship. Read more:

• SSI and Guardianship - A New Credential Type (blog 1/3)
• SSI and Guardianship - A practical Experiment (blog 2/3)