Digital Wallet Design for Guardianship

This article is part of a series that we’re writing on how we might best implement a digital model for Guardianship, and what that might mean in our personal and professional lives.

The articles are based on the work we (Jo Spencer and John Phillips) performed as co-chairs of the Sovrin Foundation Guardianship Working Group and our work with the Technical Stream of that Working Group.

The previous articles in this series so far are:

This article focuses on the role of the [digital] wallet in a guardianship arrangement. In particular it considers what, if any, are the implications for wallet design of two documents published by the Sovrin Guardianship Working Group: Implementation Guidelines and Technical Requirements. In addition, it considers some of the alternate suggestions that have been made for wallet design to support Guardianship services.

Many of us will be familiar with the apps on our phones such as Apple Pay, Google Pay, and Samsung Pay. The first release of these products typically enabled payments using the mobile phone platform (hence the “Pay”​ in their names), increasingly they can also support features like travel cards, loyalty cards, and ticket and pass saving. For the purpose of this article, we will consider these apps to be examples of digital wallets.

Self-Sovereign Identity wallets are also digital wallets, but focus on storing and presenting verifiable data. A Self-Sovereign Identity (SSI) wallet shares some of the same features as the existing apps: it stores things securely, is accessed (opened) by the user using a biometric or pin-code entry (this in addition to accessing the phone itself), and they support communication (data exchanges and transactions) between the wallet and external systems via the phone’s communication channels.

A simple overview of an SSI wallet is given below.

Using this schematic as a model, the three SSI wallet building blocks are as follows:

Agent is providing functionality to support the wallet (how to process a connection request, proof request, generate a proof response, back up a wallet etc.)

Storage is providing secure storage of things like Keys, Master Secret, Verifiable Credentials. Wallet design should make the best use possible of the device’s native secure enclave or hardware for this.

Comms implements the DIDComm protocol and W3C DID methods (preferably several) over the communication network(s) available to the phone

For the purpose of this article, what makes a wallet an SSI wallet is that it supports two major standards: W3C Verifiable Credentials and DIF/Aries DIDComm, and the cryptographic capability to encrypt/decrypt and sign data.

Many people (myself included), expect that the major mobile operating systems and platform providers (such as Apple and Google) will embed W3C Verifiable Credential / DID and DIF DIDcomm capabilities into their wallets in the near future, making them capable of supporting SSI transactions as well.

Several (currently around a dozen) purpose built SSI Wallets are available through Apple and Google stores as complete wallet apps from a number of manufacturers. We use a number of these when exploring the various implementations of SSI product stacks, including wallets from Evernym, MATTR, Trinsic, IdRamp, Esatus, uPort, and other “related” wallets such as Blockcerts. While SSI Wallets share the same fundamental capabilities, each wallet will have its own UX and may provide some specific or unique capabilities.

Several SSI wallet manufacturers are now providing SDK solutions so that existing apps can embed SSI capabilities. This very important initiative means that we can have an “SSI Inside” approach to apps such as state government or national government service apps which already have a large take-up and functional footprint but may not have authentication, verification, and interoperability capabilities.

Some apps/wallets have single purpose designs, such as the IATA TravelPass. This embeds IATA’s knowledge of the business rules for travel and current requirements/restrictions to help inform travellers of the credentials they will need in order to travel, and to provide them with a “good to go” confirmation for their destination on receipt of all necessary credentials.

A diagram showing SSI Wallet capability as an embedded SDK within an existing app is shown below.

One thing to remember about digital wallets is that it’s not just about mobile phones. While for users wallets will most often be multi-function capable “smart” edge devices (such as phones and tablets), other bespoke devices are possible (e.g. NFC capable simple chipset designs may be useful for employee passes, travel passes, student passes etc.), and web wallets are also possible. And while not the focus of this article, it is worth noting that forms of wallet functionality are also used by organisations who issue and verify credentials.

For this article we will focus on smart mobile device wallets, but the discussion in terms of required functionality for guardianship for users extends to web wallets and other edge devices.

There are two key Sovrin Guardianship Working Group documents for this discussion, one providing implementation guidelines, and the other technical requirements for guardianship in the context of W3C Verifiable Credentials, W3C Decentralised Identifiers and the Trust over IP framework. These documents were published by Sovrin in May 2021.

A key proposal of these documents is that a guardianship arrangement is defined in a verifiable guardianship credential using the W3C Verifiable Credential Data Model and issued to the Guardian. There are a number of elements proposed for the guardianship credential type, they include:

[Note that there are refinements possible on the use of these attributes. For example, the Issuer organisation might also indicate the individual who authorised the arrangement, Guardians and Dependents are expected to be people – but it is possible to consider organisations in these roles too, see Jo Spencer’s article on discussing Guardianship and Organisations.

The Implementation Guidelines document proposes that a recognised authority in the Jurisdiction issues the guardianship credential to the Guardian, who then holds it in their [digital] wallet. The schematic below shows how this interplay works – the Implementation Guidelines document contains the reference mental model.

Note that the mental model in the Implementation Guidelines allows for the possibility that there may be more than one Guardian for a dependent, and that a Guardian may be responsible for more than one dependent. The design replicates a digital equivalent of the document(s) that are provided as proof of guardianship to guardians.

While we consider that a dependent could also receive a credential that confirms their guardian(s) and arrangement details, clearly this may not always be possible given that dependents have a range of abilities and not all may be able to use, or have access to, their own digital wallet.

In aiming to mirror the real world approach, we wanted to ensure that all existing legal and societal safeguards and enablers were available, and that no new risks were introduced. This is reflected in the preference stated in the documents that the digital wallet design only needs to be a “Self-Sovereign Identity” wallet that supports W3C Verifiable Credentials and the DIF DIDcomm protocol.

The technical stream authors of the Sovrin Guardianship documents (myself included) believe that standard W3C verifiable credentials designed for guardianship as described in the documents can provide immediate benefits using the existing wallet and infrastructure capability of SSI.

However, there are some interesting opportunities that might enable our digital world to improve over our physical world in some areas. We want to see if we can safely address these in our digital designs so that our digital world is as good as it can be and work with, and add value to, our physical world along the way. 

We’ll explore these opportunities by considering three phases of the guardianship role: 

For each phase we’ll explore how what we might need to do as a guardian can impact our wallet design. Along the way we’ll explore some of the guardianship functions that have been proposed by others for wallets.

So you’ve just been appointed as a guardian, congratulations and thanks. How much do you know about the dependent and their life to date so that you can help them?

One of the first challenges for a guardian is making sure they have appropriate knowledge of the dependents’​ existing situation and arrangements. A guardian may not have perfect knowledge of the dependent for a number of reasons. In fact it could be argued that no person has perfect knowledge of another person. From a practical point of view, this imperfect knowledge situation can arise when adults need to care for another adult who has been independent until now, or when foster parents take responsibility for children that they don’t already know. Having the necessary background details such as the physical and digital things owned, and subscribed to, and the medical and education history, can enable the carer to provide better care for the dependent. In some situations knowing these details might be essential to the financial, social and medical well being of the dependent.

In the physical world, and assuming that this is within the rights and duties of our role as a guardian, we might look through wallets and desk drawers, and might try to explore computing devices and phones to see what online resources are necessary for the dependent. 

This is hard enough – people might understandably “hide” the things they think important and valuable to them, and computing devices are typically protected by passwords and biometrics. But what if in addition to this, the adult had a digital wallet in which they kept their digital credentials – shouldn’t we be able to gain access to this wallet and/or control it in some way?

Let’s consider wallet control first. There have been a number of suggestions in the SSI community that the Guardian should be able to control (in one way or another), the dependent’s wallet. This idea was included in the 2019 release of the Sovrin Guardianship whitepaper (now under review). Our more recent thinking is that we should not allow this. Two main reasons:

So, if control isn’t literally “control”, then perhaps we need a way for the guardian to gain access, to “see”, into the dependent’s wallet so that they can know what relationships and credentials the dependent holds that may be important to them as the Dependent’s Guardian?

Well after some consideration, we think not, at least not in the general sense. Here’s a scenario to explain why we think this way. Imagine a situation where an adult was independent before they became dependent. In this scenario, they weren’t expecting to become dependent, and have not made any preparations, and now that they are no longer independent they cannot (or will not) cooperate with their guardian. In this situation we might want to explore some options to give the guardian some insights. Let’s look at two:

[We might see parallels between this second point, that a “trustworthy organisation” should always have some way of accessing encrypted information, and recent Government Acts and court cases such as Apple (and Google) vs the FBI in the US, and the Australian Government’s Telecommunications and Other Legislation Amendment (Assistance and Access) Act 2018,1 or TOLA Act)]

OK, so what if the dependent makes prior arrangements before they become dependent? Well our instinct should be to support that kind of voluntary, conscious decision with appropriate technology capabilities, but again we need to be cautious. 

Imagine if we enable wallet owners to identify someone who can open/view their wallet if they are unable to do so themselves [Password managers like LastPass already provide capabilities like this], this would allow the forward thinking adult to name someone who they trust to access their wallet in the event of them being incapacitated, and it seems like a good idea. However we need to exercise caution.

People (all of us) are vulnerable to coercion. We might know that we’re being robbed when we are physically forced to open our wallet, but would we be as aware (and cautious) of risks if we’re asked to add someone’s name/details to a wallet as a fall back? What if the person we trust becomes untrustworthy, or is the victim of coercion themselves? If we can name a person we trust to have access to our wallet, can a person we don’t trust force us to name them and give them access?

So perhaps we’d best not allow wallets to open to anyone but their one true owner? 

Despite our caution, we think wallet design in the areas of planning and establishing guardianship arrangements is worth exploring, and that benefits can be realised from some well designed (ethical/social/risk) smartness here. For example, we can anticipate that we’ll need to be able to organise the things we hold in wallets (since we expect to hold a lot of things in our wallets). And since no filing system or human memory is ever perfect or complete, we will need a way of searching for things in our wallet. If we label our credentials as certain “types”​, perhaps we can have wallets that selectively disclose only the types of things that we’re happy to be disclosed? Alternatively we might declare areas of our wallet to be accessible by certain (verifiable) people in certain circumstances and “put”​ the credentials we select in those areas. Emergency Health data (allergies, medications, DNR, next of kin, organ donation, etc.) accessible by health care professionals in an emergency is the classic example.

In our opinion, this is an attractive line of thinking, but it needs to be properly explored by an appropriately diverse group of experienced people. We know that if it isn’t done well, it will add complexity and vulnerabilities.

So from our point of view, no need guardianship specific functionality for the establishment phase, at least for the moment.

OK, you’re looking after a dependent person now, and you’re helping them live their life. Excellent. 

As they live their life, all people, dependent or independent, will experience events and accumulate stuff related to them: physical and digital things, new medical, education, and financial events will be experienced.

Where does the Guardian put the credentials that verify what their Dependent has achieved or experienced? Do you put their credentials in your wallet? 

Let’s be a little more precise about our words here. We need to think in terms of the identifiers of the stakeholders involved. A Verifiable Credential is issued by an Issuing Authority (an organisation typically), to a Holder (a person typically) who stores it in their wallet. The verifiable credential also contains information related to identifying the Subject (which may or may not be the person to whom the credential is issued). This means that a Guardian can receive a credential that verifies an event (an academic achievement, award, medical event, prescription etc.), declares the Guardian as the holder, and the Dependent as the subject of the credential. 

This line of reasoning assumes that a Guardian will need to prove something about the event concerning the Dependent to another person or organisation – this seems likely. Note that if the Dependent is able, then it is also possible to provide them with a credential that they can hold and/or that can be held for them in anticipation of them recovering independence.

This means that ‘yes’, the Guardian can receive credentials related to the Dependent. However the Dependent is the subject of the credential and the holder is the Guardian. The Guardian is not receiving the Dependent’s credentials, they are receiving credentials about the dependent that are appropriate for them to have given their rights and duties as a Guardian.

Here it might be helpful to think of our life experience with birth certificates / records / attestations. This certificate is typically given to the parents (and saved in some central systems) shortly after the birth event. The child doesn’t get to see it for quite some time, and usually needs to ask for their own certificate when they become an adult and need to prove things for and about themselves. This need for multiple instances of the certificate is necessary since the event was not only a point in time when the child was born, but also when the parent(s) became a parent(s): several people can be stakeholders in an event and each may have good reason(s) to need a credential to prove it.