Detailed Capabilities of Wallets & Agents #DigitalWallet Part 4/16
This post is an excerpt from an upcoming report entitled The Current and Future State of Digital Wallets, which is being shared here as a 16-part series. To receive a copy of the report, please click here. This is the fourth post. For the first post click here, for the previous post click here, and for the next post click here.
The earliest Digital Wallets hold a limited set of information. Mainstream Digital Wallets like Apple Pay and Google Pay allow simple information to be “carried” inside them:
- credit cards and cash
- tickets (e.g. plane tickets, event tickets)
- Other basic credentials (e.g. loyalty reward virtual card)
- A mess of receipts and slips of paper
Over time more and more types of information will be useful in a Digital Wallet. This section briefly describes some of the capabilities that Digital Wallets are beginning to (or will) support.
Credentials — Receiving, Offering, and Presenting
In order to use Credentials our Wallet needs to be able to:
- accept them from others
- request them from others
- respond to requests for them
- and offer them to others
While those capabilities above seem so simple the protocols to do each of them are just being created. Most early stage Wallets have the ability to do some of these tasks but the user experience is so complicated that only the most dedicated users will ever attempt to perform them.
The Credential Lifecycle needs to be supported as well, where Credentials may be revoked, updated, and expire.
Authenticating — Logging You In
One of the more exciting uses of Digital Wallets is that they allow us to log in to websites and other services with far higher security. They can also make logging in much simpler too. There are two early use cases that are actively being used in various industries including banking:
- Second-Factor Authentication (2FA) — 2FA is typically used in combination with traditional username and password. Either as part of logging in or for high-value transactions a Digital Wallet can be used to provide 2FA capability. This increases the security and relative ease of use as most 2FA solutions require dedicated devices or software that may be difficult to use.
- Passwordless Login — Multiple initiatives are underway to remove the need to use a username and password. Because our Digital Wallet provides multiple factors that fit authentication (something you have, something you know, and something you are) the credentials and connections that it manages can provide better security and replace username and password use. There are multiple standards that apply. We’ll discuss them in Section 6.4.8. 2FA/UFA Use Cases.
Our Digital Wallets can help us transition to a much simpler and more secure way of accessing the systems that we use daily.
Organizing
Managing many (hundreds or thousands) of credentials mean that a Digital Wallet must be able to organize information to allow its owner to find the information they need. Organizing the stuff in a Digital Wallet is going to be one of the key challenges for the foreseeable future — we just don’t have user experience paradigms that work with the amount of Stuff we can keep in a Digital Wallet.
Being able to find information in your Wallet is crucial. However, knowing what information may be used to satisfy a request makes it easier. Imagine a police officer asking for your driver’s licence — that’s a pretty simple request and easy to respond to (hand your driver’s licence over). What about someone requesting an address from you? Depending on the level of assurance required you may present a phone bill, a library card, or just a piece of text that you typed in yourself. Managing the pieces of information is getting hard at this point.
Once we start to look at the other “Stuff” in our wallet we quickly get to the point where hundreds or thousands of items need to be managed. That is simply beyond the capacity of most folks. Our Digital Wallet needs to help us here. Our Digital Wallet and the Agents that are contained in it have more context — about what we are doing, what is required, what options we have, and more. Agents and the user experiences that evolve over the next few years will be helpful in managing the increasing amounts of information that we hold.
Rendering
The current leading solution for specifying digital credentials is the W3C Verifiable Credentials specification, though the specification is still in early days and not a full-fledged standard. It allows for rich data to be shared but there is no direct consideration of how the data will be shared visually. The technical details behind sharing a credential digitally is understood — but what a credential looks like to a human isn’t. We don’t have any norms about what a digital credential should look like. Some want a digital driver’s licence to look just like a physical one — but others feel vehemently that is inappropriate.
For text data the only consistent approach is to use the key names (e.g. “date_of_birth”) and the value associated (e.g. “1970/12/31”) — which leads to a very poor user experience.
For non-text data, such as images, there are no clear guidelines about how a credential should look when viewed.
Standards and best practices will evolve, likely based on a subset of HTML and CSS for simplicity and security.
Personas
When we look at our lives we realize that we aren’t a single “person”. We are different depending on who we are dealing with and what we are doing. We may have multiple different relations with a particular person — a close friendship and a business partnership for example. Yet most systems see us as a singular being.
Digital Wallets will need to support the concept of Personas — allowing us to represent ourselves as needed. The need that drives how we present ourselves may be personally driven (e.g. I decide what to share with you) or mandated (e.g. border control has a very limited set of credentials that it will accept). Regardless, we need to be able to support the multiple personas that we use on a day to day basis.
Private Connections
A Digital Wallet maintains connections to various other entities: People, Organizations, and Things. These connections need to remain private so the owner of the Digital Wallet can maximize both privacy and security. To that end a Digital Wallet should use unique, pairwise decentralized identifiers for each and every connection that it establishes. These pairwise DIDs allow each relationship/connection to be controlled independently (e.g., keys rotated, DID terminated/burned). The benefits of pairwise DIDs amongst many others, include reducing correlation risk and allowing for key rotation without impacting other relationships.
Decentralized Identifier (DID) A new type of identifier developed for decentralized systems as defined by the W3C DID specification. DIDs enable interoperable decentralized Self-Sovereign Identity management. A DID is associated with exactly one DID document. The Sovrin Technical Governance Board defines the technical specifications for a Sovrin DID in the Sovrin DID Method Specification. Source: Sovrin Glossary
Emergency Access
A Digital Wallet will hold crucial information that may be useful in the event of an emergency. Various types of information can be compartmentalized and made accessible through various methods under various conditions such as:
- medical emergency — first responders and medical personnel/institutions will need access
- death or incapacitation — would potentially require legal intervention and consideration of legal authority
We see early Wallets like Apple Wallet allowing for a emergency mode. Your author provides information about a peanut allergy that anyone can use if they have access to his phone. The information is very limited and there is no restriction to who can access the device. However, if a bona fide first responder could prove that they are a first responder (e.g. if they had a First Responder credential that our Digital Wallet could query and confirm), we may release far more information.
So our Digital Wallet needs to consider what information can be provided and under what conditions it will allow release. There are many areas that need to be explored. See section 6.4.11. Break Glass In Case of Emergency for an idea of the research and development that is needed. Trust Hubs/Registries
In order to “trust” the various Credentials that end up in a Wallet we need to be able to know that the Issuer of the Credential is trusted in the first place. Every Credential is created by an Issuer — so knowing how that Issuer’s authority is established is crucial. Digital Wallets will use and maintain Trust Hubs and Trust Registries to know which Issuers should be considered “trusted”.
We need to know that our Digital Wallets are using the right sources of truth, especially in an increasingly decentralized world. As time goes on there will be definitive sources (e.g. a Trust Hub that lists all government Issuers for a country) but initially the opportunity for spoofing and fraud needs to be considered. An enterprising young person may easily create a series of fake Digital Identity Documents masquerading as a province that hasn’t yet started doing so.
Further detail can be found in Section 6.4.1. Trust Hubs.
Compliance & Monitoring
Depending on the needs of a Digital Wallet owner there may be a need to invite Agents that perform monitoring and compliance of particular activities in a Wallet (e.g. a bank may require that an enterprise attach an audit agent that relays information about particular activities).
We therefore need to establish whether we bring a monitoring Agent into our Digital Wallet voluntarily or under mandate. Consider the following examples:
- Health Receipt Monitor — imagine a software agent that makes sure all of your health receipts go into a list that you can easily share with your health insurance provider.
- Company Credential Usage Monitor — imagine your company requiring an Agent that monitors and logs any of the authentication or signing activities that you are doing with the company-issued Credentials.
Schemas & Overlays
Digital Wallets will be sharing and using Credentials of all types. Like any other data-centric system (yes, a Digital Wallet is a system) we will need to get some kind of standardization about how certain things look at the data level. Credentials like driver’s licences, passports, and even receipts can use well-known Schemas. When a Credential uses a well-known Schema our Digital Wallet can do things for us that make our lives much easier.
For example, using well-known Schema (more in R&D Schemas and Overlays) will help us exchange key information — including contacts, receipts (with the ownership that we discussed earlier), and more.
Additionally, by using well-known Schema we can also use a technology called Overlays to ease how we do things. Overlays allow use to protect private information, view things in standard ways, and more.
A simple example of the use of an overlay is shown below. United Airlines tickets in Apple Wallet adds a graphic marker (yellow “hand drawn” circle) to indicate a change that has occurred to a Credential — in this case, a gate change.
STORY: Overlays Example — Driver’s Licence As an example, imagine you are pulled over by a police officer and the officer requests your driver’s licence and registration. It would be normal for the police officer to require the full details from your driver’s licence. Using that same Credential at a bar to prove your age of majority would be a normal thing to do as well — but they don’t need the same level of information. The bar needs to know that you are old enough to drink but they don’t need the intimate details that are in your driver’s licence Credential.
An Overlay can support the above case. Your Digital Wallet would handle most of this for you. When asked by a police officer for your driver’s licence they would also provide the law-enforcement Overlay that they require. Similarly a bar could ask for the credential with an age-of-majority Overlay and your Wallet would handle that. Your Wallet can also protect you from privacy violations — for example, if the bar asked for your driver’s licence but asked with the law-enforcement Overlay it would flag the activity as suspicious, warn you, and possibly even report the establishment to authorities.
Revocations & Expiries
Credentials in an SSI world are held — not necessarily owned. Much like a driver’s licence is held by a person, it is actually owned by the government agency that issued it.
REVOCATION — if a Credential is revoked, we need to understand what our Digital Wallet does — does it remove that item? Does it look for a replacement (a revocation of a driver’s licence may just mean that a newer version has been created)? Does it automatically get removed from our Digital Wallet?
EXPIRY — similarly, some Credentials are of no utility past a particular time — such as concert tickets. Depending on what we decide is important our Digital Wallet may clean itself up (e.g. move expired tickets to a trash folder) or require us to keep things in order.
Offline Operations
Digital Wallets may need to be able to operate under conditions where portions or all of a network are unavailable. Where there is a critical need for operations offline, multiple pieces of information will need to be cached locally:
- Cached Issuer Information — As critical issuers are offline, Wallets will need to know what the latest state of their Issuing DIDs (e.g. Public Keys).
- Revocation Registries — These will allow offline use of Credentials with more trust than is currently available with physical credentials.
- State Information — Digital Wallets will maintain a state that is relevant for various interactions that are occurring offline and simultaneously online. Reconciliation of activities that occurred during a period of being offline will be crucial.
Keys and Secrets
At its heart a Digital Wallet manages various different cryptographic keys and other items that need to be highly secure. Managing the creation, rotation, and revocation of these is crucial to ensuring that our Digital Wallet remains secure. These aspects are crucial to ensure that our wallets remain safe and usable.
Secure Hardware Integration
A Digital Wallet must leverage secure hardware capabilities such as trusted execution environments, secure enclaves, trusted execution environments, hardware security modules, etc. The use of these modules increases the overall security of your Digital Wallet. A Digital Wallet that avoids the use of such hardware should be considered suspect. Further if there are secure libraries (e.g. certified FIDO U2F SDKs) they could be live-signed at runtime to ensure that they haven’t been tampered with.
Notification
One of the key uses of a Digital Wallet application will be to provide information for its owner — whether that is a person or an organization. Messages for using Credentials, signing transactions, etc. will require notification. Depending on the use case these notifications may need to be on device or integrated into messaging systems for dissemination.
Notification use cases are becoming well understood with Android and iOS providing OS-level notification. Digital Wallets will have multiple notification modes — some of which may require rethinking about how they are handled:
- Receipts — message receipt, receiving Credentials and other items, etc. are fairly routine.
- Time-sensitive — where there is a need for the Digital Wallet owner to act in a timely manner (e.g. “press OK if you are talking to your bank.” or “Please authorize this wire transfer”). Signing or authorizing activities will likely need this time-sensitive capability.
- Modal — messages that need to interrupt the flow of any other activities with the Digital Wallet.
Backup & Recovery
Losing your wallet is no fun. We all get nervous when it happens. The questions immediately start flowing:
- will I find it?
- if I do find it will everything be in it?
- what did I have in it?
- how can I get all the cards and identity documents replaced?
- is someone using my cards and info to steal my “identity”?
Recovery from a lost wallet is painful — especially if we have been compromised through fraud and/or identity theft.
It is important to understand that a Digital Wallet differs radically from a Cryptocurrency Wallet. Typically a Crypto Wallet can be restored by using just a Recovery Key. The restoring is done by reading the blockchain/ledger of each cryptocurrency to rebuild a history of activities. With a Digital Wallet the vast majority — potentially 100% — of the data are not stored anywhere publicly accessible. The contents are typically pushed to a Digital Wallet by an Issuer. This means that there is nowhere to go unless you have made backups.
In the digital world there are options evolving — but you need to make certain that you have all your bases covered. There are two key things that differ with a Digital Wallet from a physical wallet:
- if you have a backup and recovery plan, you can recover your Digital Wallet completely if you have the keys.
- you need the keys to unlock the backup — and to take it back over if someone has compromised it. This also means that if you have lost the keys you may never get your Digital Wallet back.
At least, that is the promise of the emerging Digital Wallet industry. No known examples show, in the wild, how someone can re-assert control of a stolen Digital Wallet. But there are concrete plans and protocols being developed that will allow for this. (See 6.4.9. Backup & Recovery).
But what do we need to back up?
Fundamentally there are two things that you can lose — and which need you to have a Backup available in order to recover your Digital Wallet:
- the keys and seed that protect the Wallet itself
- an encrypted backup of your Wallet contents
If you have both of those you can likely recover your Wallet relatively easily. If you don’t, you are in trouble. Be sure that each is backed up somewhere that you can trust and access.
Vault Support
Wallets can only hold so much — and it isn’t great to carry it all. The ability to keep some items in other places for safekeeping is crucial. Much like in the physical world, we need to be able to move things to and from various storage areas: Vaults.
In the physical world we keep many of our assets with various “Vaults”. We keep our cash in banks (it’s actually just a digital representation of a promise to provide you cash, but hey), stocks with financial advisors and broker/custodians, insurance policies, and many other places.
Why wouldn’t we do this in the digital world? The pure “decentralize the world” community considers this anathema, but we don’t all want the headache and worry that comes with holding everything.
Assuming we want to be able to move things from our Wallet into a Vault and from a Vault to our wallet, we need to make sure our Digital Wallet is capable of supporting a Vault.
In the R&D section (see section 6.4.10. Vault-as-a-Service) we’ll discuss more detail about what a Vault is and what we, as an industry, need to learn and develop to make these a reality.
Multiple Device Support
We often use multiple wallets in the physical world and use multiple devices that we can use as a Digital Wallet. The reasons for using multiple physical wallets are manifold:
- travel vs. day-to-day — when travelling we may need our passports (en route) or want a completely minimal set of things (e.g. at the beach)
- style — the rugged carry-everything wallet doesn’t always do the trick when you’re dressed up
- purpose — some days a bank card and a driver’s licence is all that is needed
The devices that we carry are similar. We may have a smartphone and a tablet that we use regularly. An officer in a company may keep company Credentials on a particular device that is kept under lock & key other than the times when is it used.
Synchronization
Key to supporting multiple Wallets is the ability to synchronize information between them and with any kind of vault storage. Carrying all things at the same time in each Digital Wallet likely doesn’t fit the bill for usability. Some devices will be purpose-driven (e.g. corporate tablet for work; personal tablet for home) and others not suitable to carry too many Credentials.
As we look at where we will have Digital Wallets and the Vaults we see that there are many places where we will need our “Stuff”. Similarly there are some devices where we explicitly do not want some Stuff. As examples:
- we may not want much to be available on our smart watch
- we may want our recovery keys to only be in our Vault
- we may want to separate some key information between our smartphone and tablet — to ensure that we can recover if one of those devices is lost
Over time our Agents will get smarter and handle the synchronization that we need relatively seamlessly. For now this will be a very manual and onerous step.
Selective Disclosure
Privacy-respecting credential usage means that an Identity Owner must be able to limit what information is shared with others. The ability to share limited subsets called Selective Disclosure. Using attributes (aka Claims) from one or more Credentials allows a Person to decide what information they want to share.
Selective Disclosure A Privacy by Design principle of revealing only the subset of the data described in a Claim, Credential, or other set of Private Data that is required by a Verifier. There are many techniques for achieving Selective Disclosure. One of the primary techniques used in Sovrin Infrastructure is Zero Knowledge Proof cryptography. [source if applicable]
The classic case of using a particular credential for multiple purposes can explain the utility of Selective Disclosure. Using a digital driver’s licence one can easily imagine the following unique presentations of the credential:
- Full Disclosure — present a full driver’s licence Credential, with all Claims exposed, to a law enforcement officer
- Partial — present a very limited portion for proof of “Age of Majority”. Alice presents only her picture and a binary value that says she is “over 19”.
The use of Selective Disclosure, in the context of the above example, can benefit from overlays (see Schemas & Overlays). In the Driver’s Licence example we may have Overlays called Law Enforcement (full) and Age of Majority.
Many groups feel that governments can just issue multiple credentials at once, negating the need of Selective Disclosure. What isn’t understood is that government agencies have extremely narrow definitions of what they are allowed to put into a Credential. In the case of a DMV, they don’t have the mandate to issue an “Age of Majority” Credential. That’s a different department/ministry — and the mandates are generally quite different. Selective Disclosure allows departments to focus on their mandate while allowing people to share appropriate information.
Manage Guardianship & Delegation
Digital Wallet use implies that a person is fully able to perform all of the actions required to use it. What happens when a person isn’t capable or willing to perform what is needed — and needs someone to act on their behalf? There are two main things to consider here:
- Guardianship — where we are explicitly acting on behalf of someone who can’t act
- Delegation — where we are performing duties on behalf of someone because they have delegated the authority to us
DELEGATION
We don’t do everything for ourselves. Often we have other people do things for us — because we have asked them to do so:
- pick up kids from school
- file our personal or corporate taxes
- guard our assets
GUARDIANSHIP
At other times in our lives there are needs for someone (an Identity Owner) to take over things for us — because we can’t do them. This is where Guardianship comes in. Guardianship applies when a Dependent can’t perform — because they are incapable or not allowed. Examples include:
- parents acting on behalf of children
- an adult acting on behalf of a mentally or physically incapable person
On a technical level, the key difference between Delegation and Guardianship is control of the keys:
- under Delegation, both Identity Owners have a set of keys;
- under Guardianship, the Guardian is the only holder of keys. (Note: a Guardian needs to have 2 sets of keys — their personal keys and keys for the Dependent.)
Digital Wallets need to be able to handle these subtle differences. The use of Personas may assist in managing the complexity.
Messaging
In the physical world we ask each other for Credentials and other things that we hold in our physical wallets. In the Digital Wallet realm we need to parallel those messages:
- “Could I see some government identity?”
- “Do you have the receipt?”
- “Can you provide proof of address?”
These queries become much simpler when they are digitized — when someone needs your government identity to prove you are legally allowed to enter a drinking establishment, we can request things very specifically:
- we accept the following government Digital Identity Issuers — Ontario, British Columbia, and Alberta
- we will only use the “age of majority” Overlay as approved by each of those Issuers
- we will delete the information once we have logged non-identifying information
Codifying these digital interactions are crucial.
But those examples only show interactions that mimic how we use our physical wallet.
The Agents in our Wallets can do far more.
- Negotiate Payment — an Agent can offer various payment approaches and currencies.
- Consent Management — an Agent can maintain a line of connection along with the consent(s) that go along with the relationship.
- Approvals — when the holder of the Digital Wallet needs to authorize transaction for themselves or others (e.g. under a Guardianship or Delegation case) digitally signed authorizations can be provided with ease.
- General Communication — Digital Wallets may provide a shared messaging capability that other apps could use for decentralized messaging.
Signing
The cryptographic keys in a Digital Wallet can be used to digitally “sign” various different digital items (e.g. contracts, messages). While this capability sounds abstract many of us are already doing this — when we use Apple Pay or Google Pay we are digitally “signing” the payments with our device. That device is tied to the biometric or passcode that locks our phones.
So what is different about a Digital Wallet? There are several key differences:
- Who is Signing — a Digital Wallet allows you to control which Digital Identity Artifact(s) you are using to sign things. This means you can have different ways that you sign different things. Imagine being an employee of a credit union that you have an account at — you may be signing things as an employee or as a member of the credit union. You can keep those separate in your Digital Wallet (see section 4.3.5. Personas).
- It can provide you with the record of activities and keep documents that you have signed safe for you.
- A Digital Wallet can use zero-knowledge proof approaches to sign without needing to identify you directly.
When you are using your wallet to sign for transactions that only invoke you, things are simple. However, when you are one of multiple people who needs to sign/approve something, your Wallet needs to handle a multiple signature (multisig) approach. Various cryptographic approaches will need support in your Digital Wallet.
Originally published at Continuum Loop Inc..
