Guardianship for the benefit of all
We all experience guardianship in our lives in one way or another: we are looked after as children, we look after children, we care for and act on behalf of other adults, we are cared for as an adult. Guardianship can be a temporary arrangement to allow people to build a new life for themselves, and it can be a long term arrangement to enable people to live as independently as possible while describing who provides what care to them. Guardianship spans the beginnings, middles, and ends of our lives.
Yet despite the universality of guardianship, and its recognition in laws around the world, it is nowhere to be seen in our digital lives. Our digital systems typically try to make sure that it is us, and only us, performing an action on any system. Many systems make it an offense to use someone else’s account, even if acting on their behalf under a legal arrangement.
Guardianship spans the beginnings, middles, and ends of our lives.
We need a way to give guardians and dependents a digital, legally recognised, verifiable confirmation of the rights and duties of their relationship. We need this so that they can prove relevant aspects of the relationship to others, when they need to do so. We need this to meet the needs of refugees, people living with dementia, parents, carers and the executors of wills. We need this to be more human in our digital lives.
Recognising this need in 2019, the Sovrin Foundation created a task force to explore guardianship and in late 2019 published a whitepaper on guardianship. The whitepaper (here) explored a number of issues, presented new concepts, and included links to videos of two significant use cases: Mya, a young refugee girl arriving at an aid camp; and Jamie, a married senior living with dementia.
Producing the whitepaper evidenced the need for more work, so the Sovrin Foundation chartered a Guardianship Working Group in early 2020. We (John Phillips and Jo Spencer) volunteered to be the co-chairs of the APAC region with Jamie Sterling and Philippe Page providing the initial Americas and EMEA coverage.
The Working Groups hosted a meeting every month for their region, inviting speakers and discussing topics and existing projects that are relevant to Guardianship. Alternating between regions meant we had a meeting planned more or less every two weeks. These meetings have continued into 2021.
Amongst other objectives, the Working Group was chartered to produce two documents: an Implementation Guide, and a Technical Requirements document. The context for these documents was guardianship using the building blocks of Self-Sovereign Identity (W3C Verifiable Credentials Data Model and W3C Decentralized Identifiers), and aligned with the emerging framework of Trust over IP.
In the first few months of 2020 the Working Group created a Technical Stream to work on the documents, the Technical Stream members were:
- Sterre den Breeijen (NL)
- Tim Janssen (NL)
- Rieks Joosten (NL)
- John Phillips (Aus)
- Ravi Sapkal (NZ)
- Jo Spencer (Aus)
In April 2021, after a year of Technical Stream work synchronised through weekly (and sometimes twice weekly) video conferences straddling Australia, New Zealand and the Netherlands time zones, the first releases of these two documents were published by the Sovrin Foundation.
This article gives an introductory background to the production of these documents as well as highlighting some of the key lessons we learnt.
This work has convinced us that Guardianship is vitally important to our digital lives, and that it is vitally important it is “done right”.
Getting to Simple
When we started our work in 2020 on the technical requirements document. We thought it would be simple to capture technical requirements for guardianship, but it turns out that “getting to simple” was hard.
Initially we concentrated on the two use cases in the whitepaper and added in our own experiences in systems engineering on what a system supporting guardianship would need. But the use cases contained many unique considerations, options and solutions, and we also began to see that we risked defining a specific instance of an operational system, rather than higher level, system independent, technical requirements. And as we began to uncover the different legal frameworks and processes that we each understood by guardianship, it began to appear to be an impossible task. We realised that we couldn’t (and shouldn’t) try to “solve” guardianship as a technological challenge.
Thankfully other members of the team (in particular Rieks Joosten, who was also working on a parallel project with eSSIF-Lab) convinced us that we should (re)start by building a mental model of guardianship that could identify and describe the elements and how they fitted together. The mental model would ensure that we kept the concepts simple and consistent, that we shared an understanding of their meaning, and that we were able to consider the implications of the different interactions in each of the use cases.
Building the Mental Model in the Implementation Guidelines document allowed us to simplify the Technical Requirements document so that it could focus solely on requirements for guardianship in an SSI / Trust over IP context.
Finally we had a way to simple. As a team, we found by annotating the “Design Squiggle” popularised by Damien Newman, we had a good indication of our journey.
In all, this release of the Implementation Guidelines document comes to 53 pages and the Technical Requirements to 14 pages, with only 24 requirements. “This release”, because we expect updates…
Key elements of the Implementation Guidelines
Early in the Implementation Guidelines document an overall diagram of the mental model for Guardianship is introduced. The figure below shows the mental model’s concepts and relations concerning guardianship, which are dispersed into three areas:
- Governance (red): this is the area in which kinds of guardianship are identified, the purpose(s) this it would serve, and the rules that apply on each arrangement;
- Define-time (yellow): here, individual guardianship types are defined, allowing them to be instantiated at run-time.
- Run-time (blue): this is where actual guardianship arrangements are established, and managed.
Taking a section from a later part of the Implementation Guidelines, we propose a Guardianship Credential type with the following candidate fields:
- jurisdiction: text that is used to identify the jurisdiction that has defined, and governs the guardianship type represented by the template, as well as every guardianship arrangement that instantiates such guardianship types. There must be exactly one such text. This text must be provided such that it is actually dereferenceable within the context(s) of its intended use;
- type: text that is used to identify the guardianship type represented by the template. There must be exactly one such text. This text must be provided such that it actually dereferenceable within the scope of the jurisdiction;
- dependent-roles: list of texts, each of which is used to identify a stakeholder role that represents an entity being cared about/for. There must be at least one such text. This text must be provided such that it is actually dereferenceable within the set of all stakeholder roles specified in the guardianship type;
- rights: list of ‘right’ objects, each of which comprises a condition, a non-empty set of roles (right-holders) and a list of actions, the meaning of which is that when the condition is satisfied, a party that performs any of the right-holder roles is allowed to execute any of the listed actions.
- duties: list of ‘duty’ objects, each of which comprises a condition, a non-empty set of roles (in the ‘duty-holder’-attribute), another set of roles (in the ‘claimant’-attribute) and a list of actions, the meaning of which is that when the condition is satisfied, any party that performs any of the duty-holder roles must ensure that every of the listed actions will have been executed, and any party that performs a claimant role can request such duty-holders to do so.
- right-holder, duty-holder, claimant: list of texts, each of which represents a stakeholder role within the context of the guardianship type. The various semantics are explained in the ‘right’ and ‘duty’ sections above.
- condition: an expression with variables, that can be roles and other facts, whose values are established at runtime, or can be provided through credentials. When an expression has insufficient data for its evaluation, evaluation results in ‘unknown’. Otherwise, it results in either ‘true’ or ‘false’. We consider a further specification of this element outside the scope of this document.
- actions: list of objects, each of which specifying a (coherent set of) action(s) that are to be performed (when the condition either doesn’t exist, or evaluates to ‘true’). We consider a further specification of this element outside the scope of this document.
Key lessons learnt
Build a Mental Model when you want to explain/explore something complicated
A mental model helps make sure you define a context in which you can all understand the same thing in the same way.
You can, and should, test your mental model against use cases, exploring questions like: “does it behave the way you expect?”, “does it accommodate the use cases?”, “will it work in practice?”
Testing leads to improvements in the mental model.
Jurisdictions are essential [in Guardianship and much else]
A Guardianship relationship is given meaning by the jurisdiction in which it is created.
Jurisdictions are often defined and recognised by the legal systems of states, countries, or international bodies. To provide a broader interpretation in our guidelines, we consider a jurisdiction to be the context in which a guardianship relationship has meaning.
Work with existing laws
Digital implementations should align with existing legal frameworks.
Guardianship enabled by technology should not require Guardianship laws to be rewritten [unless the law “is an ass” and has enshrined the use of physical artefacts in the legislature]
Put simply: Digital guardianship needs to align with, and augment, physical guardianship.
You can build Guardianship on Verifiable Credentials
W3C Verifiable Credentials are very powerful building blocks for guardianship. We need Guardianship Verifiable Credentials that appropriately define the relationship:
- Identifies the Issuer
- Identifies [and is issued to] the Guardian
- Identifies the Dependent
- References the issuing process
- Identifies the Jurisdiction
- Defines the type of the relationship
- Defines the scope of the relationship [rights and duties]
- Defines the start date
- [May] define the end date or condition
Think power of medical attorney, power of financial attorney, executor of estate…
You shouldn’t build Guardianship [solely] on wallets
The original 2019 whitepaper included discussions around wallet takeover and opaque and transparent guardianship.
The technical stream determined that we don’t want to prescribe solutions where the Guardian needs to “take control” of the Dependent’s wallet and/or needs to use the Dependent’s private keys. While these seem to make sense in specific contexts, they introduce generalised risks and privacy issues. Examples include:
- Having to have a backdoor weakens all wallet security
- Taking over a wallet risks/enables impersonation
- Taking over a wallet erodes privacy and dignity
Identified Future work
The following 7 areas of future work are identified in the documents as needing further exploration. They are presented below in a summarised format, the order does not imply priority.
- Validation of Guardianship Credentials/Types – The GCs and GC-Types as proposed in these documents have not yet been used to actually design systems that can consume them. The question that remains to be answered is whether or not they are actually fit for that purpose, and if not, what needs to be changed. Aries RFC 430 (which is about Machine-Readable Governance Frameworks, and is used to specify the credentials in the original Mya use-case) may be taken as a starting point. At a higher, more judicial abstraction level, FLINT/Calculemus might be worth looking into.
- Assurances – The purpose of having and using a Guardianship Credential is to facilitate and ensure the proper execution of the Guardianship Arrangement it represents. One obvious contribution to this is the ability to authenticate the stakeholders in their roles, as per the newly introduced Authenticator objects. However, additional contributions are needed for assurances that different stakeholders may require so as to mitigate their risks as they issue, store, or process the contents of such credentials.
- Wallet Take-Over – The approach to accessing and sharing a dependent’s credentials has been a specific topic of discussion. The ability to access another person’s wallet, access its current credentials and use them (known as Wallet Take-Over as well as holder impersonation) may be called for in specific situations, it should only be considered an option when everything else fails, because issuers nor verifiers can distinguish between the situation where the holder is, or is not, impersonated. The future work here is to ensure people understand the risks involved.
- Transparent v Opaque Guardianship Scenarios – The Guardianship Whitepaper defines different scenarios where guardianship may be visible or opaque to the verifier. The requirements that need to make this possible have not been included at this point. In this document, and the Technical Requirements Document [Ref5] we consider the transparent scenario.
- Other Representation Types – The Implementation Guidelines and Technical Requirements are focused on the representation of persons in guardianship scenarios. Other representation scenarios covering delegation, custodianship, mandates, and the ownership of things should be considered and the implications considered in combination with the guardianship scenarios.
- Updates to existing Use Cases and consideration of new Use Cases – The Technical Requirements and Implementation Guidelines documents focus on two use cases. The work has highlighted the opportunity to update these Use Cases and to consider the addition of other, new, Use Cases.
- Evolving Technology – It is noted that the technology of SSI is evolving and that this may have an impact on the Implementation Guidelines and Technical Requirements documents that should be reflected in future updates. It is also possible that the considerations in these documents may influence the technology evolution of SSI. Either way, there should be subsequent releases of the Technical Requirements document and Implementation Guidelines.
The Working Group continues to meet and work and volunteers are very welcome to join! Direct message John Phillips or Jo Spencer if you want to join.
Next posts on Guardianship
This is the first in a series of posts that we plan to release on guardianship. Each is intended to provide actionable insights on how guardianship can be implemented using open-standards supported by open-source software.
The topics we plan to cover include:
- Guardianship for Jurisdictions – the importance of recognised authorities
- Guardianship for People – Roles and Duties, Safeguards and Dignity for Guardians and Dependents
- Guardianship for Organisations – the rights and responsibilities of issuers and verifiers
- Guardianship and wallets – why wallets won’t work on their own, aka the perils of technology overreach
- Guardianship in Education – how might we recognise the rights and duties of parents / guardians for children, and how might children have appropriate independence and the ability to own their credentials as adults
- Guardianship in Health – how might we better enable support for the cared and carers in a health context
- Guardianship Financial Services – how might financial service institutions use guardianship to provide better, more secure and more caring services for guardians and dependents. What can be done right now?
- Guardianship for Society – how might governments enable better digital support for guardianship in society.
We hope these articles will increase understanding of the opportunity and need for online guardianship, and we hope they generate a dialogue, but most of all we hope that they lead to implementations of Guardianship that meet the needs of guardians and dependents and those they interact with.