Further Research and Effort #DigitalWallet Part 10/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 register here and we will get the current draft sent out immediately and a PDF of the final report when it is ready. This is the tenth post. For the first post click here, for the previous post click here, and for the next post click here.

At this point we recognize that Digital Wallets are in very early stages. Research, Development, Education and other efforts are required to help move the Digital Wallet ecosystem forward. A few concepts are explored here.

​​Trust Hubs

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. Otherwise a crafty teenager will create a DMV that issues driver’s licences which “look real” (i.e. the Credentials validate cryptographically and have data that make sense). They may even create a fake website that fools folks. But with the concept of a Trust Registry their efforts would fail.

We’ll get to a more detailed description of a Trust Registry but in this case all that a law enforcement officer’s Digital Wallet needs to know is the list of official DIDs from each province/state/federal authority that it recognizes — a very short list that doesn’t change.

In order to get lists of the Issuers (e.g. the real DMV) a Wallet will need to be aware of the the concept of Trust Registries (aka Trust Hubs).

• The concept behind a Trust Registry is that a Wallet needs to know which decentralized identifiers (DIDs) to “trust” as a source of truth. At many levels this “trust” translates to “authority” — knowing that there is somebody, centralized or decentralized, who is responsible for maintaining a list of trusted DIDs.

A Wallet will need to know which Registries are to be trusted. Over time the community will need to have Trust Registries that are anchored by various means:

• Legislative Authority — many Vital Statistics and other government Issuers. They are authoritative due to their legislative authority. Examples of these include issuers of: driver licences, hunting permits, building permits, passports, etc.
• Community Authority — some Trust Hubs will be created by communities, associations, etc. that exist through either a formal (similar to legislative) or de facto authority. Examples include: registry of licenced doctors; registry of banks and credit unions; industry associations, local business improvement areas/chambers of commerce; etc.
• Informal Authority — a Trust Hub should be able to exist with no formal authority. As an example, we can imagine consolidated reputations (E.g. Uber & Lyft combined; Yelp and TripAdvisor) that allow someone to aggregate reputation across platforms. It likely derives its authority from the larger community that “lends” reputation to them.

Web of Trust — the Owner(s) of a Wallet need to know that their Wallet is using the correct list of Trusted Issuers. Therefore a Wallet needs to be able to “explain” how it created the levels of Trust — and what anchored these trust levels. We can imagine the following chain of actions when we, as a homeowner, receive a bid folder from a renovation contractor:

• We check our contractor’s business licence which is anchored back to the province/state corporate registry.
• We check their insurance certificate against a list of Issuers on a nationally maintained list of insurance companies — a trust registry. That list is anchored back to various different province/state/federal registries that are the “source of truth” for insurance company establishment — another trust registry.
• We check the training status of all of the company’s workers as they arrive, to know that they have all the required certificates and training for the jobs that they are doing.
• We check the city to make sure that our contractor is licensed to operate. The city maintains a trust registry of businesses. We back-check the city licence bureau against their master list of Issuer DIDs. The city itself has a master DID that signed that registry and it points back to its legislative source of authority and the master list of municipalities for that province/state.

Sovrin Web of Trust Model

The decentralized, non-hierarchical trust model defined by the Sovrin Governance Framework that combines a cryptographic trust layer achieved using the Sovrin Ledger, Agents and Connections with a human trust layer achieved via Credential Exchange. The Sovrin Web of Trust Model does not rely on a single root of trust, but empowers any Sovrin Entity to serve as a root of trust and enables all Sovrin Entities to participate in any number of interwoven Trust Communities, either informally or as defined by Domain-Specific Governance Frameworks. See the Sovrin Web of Trust Model white paper. Sovrin Glossary

That sounds like a lot of work doesn’t it? Here’s the thing — we don’t have to do any of this ourselves. Our Digital Wallet should do this for us.

STORY: A Home Renovation… Let’s imagine a home renovation project with three main groups to think about:
· Homeowner
· Contractor
·City Inspector
Trust Hubs and Trust Registries allow us to know that the various credentials that are shared (e.g. proof of insurance) are real. A Homeowner can ask their Digital Wallet to verify an insurance Credential that the Contractor is real. Their Digital Wallet needs to prove a few things:
· That the Contractor was the entity that the Insurer (the Issuer) gave the Credential too. This is done inside the Contractor’s Digital Wallet — it uses cryptography to prove that they still control the insurance Credential.
· That the Credential was cryptographically signed by the Insurer. This allows the Homeowner to know that the information wasn’t tampered with.
· That the Insurer is a bona fide insurance company. There will need to be a Trust Hub that lists insurers for a particular area for this to happen.

All of the above can be done in just a few seconds and while that is being done other checks can be made. Each party involved has their own pieces of information that they need to verify.Homeowner wants to know that they have the right permits and licences for the job and that their contractor and the employees of the contractor are fully licensed, insured, and up to scratch.Contractor wants to know that the Homeowner has the right permits, licence, inspections and insurance.City Inspector wants to know that both the Homeowner and Contractor have the required permits, training, and other paperwork in place.
Paper-based approaches to verifying the above take long enough that few Homeowners ever do the checks that they should. Our Digital Wallets can get all of them done in seconds — even while we are greeting each other.

​Credential Lifecycle

When a Credential is issued the Issuer can’t just forget that it was sent out — at least not in most cases. There is a lifecycle that needs to be considered. There are many different types of credential lifecycles to consider:

• Fire and Forget — some Credential lifecycles can, contrary to the opening sentence, involve simply issuing a Credential and never thinking about it again. Verifiers just confirm validity of the signature and they are done.
• Revocable Credentials — some Credentials are issued once and may be revoked later. An example would be a one-time pass that is used up (e.g. kind of a coupon). The verifier needs to know if the Credential is valid (i.e. has not been revoked).
• Updated Credentials — many Credentials need to be updated for various reasons. An example is a valid driver’s licence that needs to be updated for a change of address. The Issuer will need to revoke the original Credential and replace it with a new one. A Verifier that looks at the original Credential may need to be able to understand that the revoked credential has been replaced.
• Expiring Credentials — a Credential that has a time limit is quite normal but there is little standardization about how that works in a Verifiable Credential realm. Additionally, it is common for an expiring Credential to be replaced by a new one that may create a dual valid Credential scenario (e.g. new credit card received before the old one expires).

Each of these lifecycles — and there are likely more — needs further R&D and education to ensure that People and Organizations understand how they work in detail. The subtle differences in these lifecycles are crucial to get right. Further, this effort can help standardize processes.

​Certification

We pretty much agree that a Digital Wallet is going to be in our future.

Capabilities will range wildly and we will likely have a combination of different Agents that do things for us.

But who will make that Wallet? How do we know that we can trust it?

​Can We Trust Bubba’s Wallet?

Imagine that Bubba’s Wallet is ranked #1 in the app store. Can you trust it?

The short answer is maybe…

We need to figure out how to digitally sign an app (Bubba’s Wallet) — so we know that when we run it, we aren’t running a hacked version. Many pieces of the app need to be certified — the application developer; any libraries they use that are core to a Digital Wallet; and any certifications that the developer holds — so we can know that our Digital Wallet is safe to use. The groups (e.g. bank, government) that we share information with and get information from need to know that our wallet is trustworthy as well.

Digital signatures of an app are fine for general use. But a Digital Wallet is going to need a lot more behind it than “I, the developer of this beast, used my app store key to submit it.”. That developer could very easily be monitoring inputs and outputs for nefarious reasons. We need assurance that the application hasn’t been tampered with and doesn’t do bad things with our information.

​Certifying Bubba’s Wallet

But how do we do that? That’s where things get ugly potentially. We need to get into some pretty hard-core certification and accreditation. Some trusted third party needs to run through the application and make sure, to some high level, that it isn’t doing nefarious (or stupid) things. That’s going to cost money — a fair bit.

Is that fair though? Is it fair to ask Bubba, the masterful developer of Bubba’s Wallet, to pay a third party $5,000 to certify his application? What if the amount is $50,000? $250,000? Higher?

Regardless of the cost, there will be some kind of certification regime — a “certified by ____” logo that needs to go beyond the cosmetics. It will need to provide real-time “not tampered with” certification. There are many areas that require thinking:

• Is there a way to tie Bubba’s Wallet into a smartphone’s trusted execution environment to generate this “not tampered with” certification?
• Who are the players that can help get this kind of real-time certification done? It’s likely the operating system providers, hardware manufacturers, banking networks and telecommunication providers will need to step in. They provide infrastructure and business services that will require highly trusted Digital Wallet technology.
• When does the cost of certification get high enough that we stifle the innovation that we need in the Digital Wallet community?
• What Organizations should be doing the certification? Do they need government approval? (Yes. Government approval in a decentralized world is a concept that needs to be considered.)
• How do we provide a digital “seal of approval” and know that the software that runs the Wallet hasn’t been tampered with?

​Rendering

Credentials are largely just a collection of attributes called claims. The visual rendering of such simple data has largely been to provide a tabular list of key names and values.

These are not the most attractive of user experiences. To a non-technical person, the idea that a digital driver’s licence could be shown as a table of values like the following is ridiculous.

Key Name Value Above: Example Physical Credential first_name TEST CARD last_name SAMPLE middle_name dl_number 1234562 issued_datetime 2012–11–30 expires_datetime 2017–11–30 restrictions 2 endorsements 1 dl_class 5 … checksum #QTRAASDV

Rendering is the act of translation digital data into something visual — taking that tabular data and making it look like something regular people can make sense of. This means taking some attributes and either hiding them (many look like nonsense to a human) or transforming the raw data into something that makes more sense.

R&D is required to understand many things:

• How can a Credential be rendered to look like it approximates an official paper or plastic credential?
• What information should be hidden from view? A Digital Identity Document may hold multiple images, for example — used for different purposes. A high-resolution image may be appropriate for official use and a lower-resolution image for visual display.
• How can you visually render a Credential while making it easy for a device to request a proof of the signed data?

​No Device/No Smartphone

The majority of Digital Wallet activity is best suited for Smartphones. That leaves out any people who don’t have access to a Smartphone. This means that Digital Wallet capabilities could create an exclusion barrier for the demographics that don’t have devices.

Research is needed to understand what options are available to those who don’t have devices capable of being a full Digital Wallet.

STORY A Pseudo-Guardian A special case needs to be considered as the Digital Wallet market unfolds. While some smartphone applications are beginning to take on full Digital Wallet capabilities there are intermediate steps being taken that may feel like they violate the idea that a person must have total control of their Wallet. One pattern has emerged that sits between a fully-hosted Digital Wallet (i.e. controlled by the host) and a Digital Wallet that is controlled by the identity owner. These intermediate solutions use cloud-hosting where the Company/Organization is hosting information on behalf of an Identity Owner. Until standards are in place, particularly for portability, this pattern will continue to present discomfort for many. There are many reasons for this pattern to have emerged:There are no fully functioning Digital Wallets yet — not at the level that are defined in this report at least.There are unknowns in the broad scale deployments of generic Digital Wallets — see 6.4.3.1. Can We Trust Bubba’s Wallet? for more on this one. Applications are focused on a very particular usage. As an example, a non-governmental organization (NGO) may host a cloud Wallet for a beneficiary where they are doing only a very specific thing — such as managing eligibility for a particular benefit. The NGO in this case is an informal Guardian. Mobile applications that are interfacing with back-end services need to seamlessly integrate while awaiting local (i.e. on smartphone) capabilities such as reliable backup and restore, agent-to-agent communications that support mobility). An expedient engineering choice here is to start with a Wallet that is effectively — through no official mandate — held under Guardianship.
The hope behind these Pseudo-Guardian use cases is that control will be handed over to the individual Identity Owners in time. Where that isn’t happening we can expect challenges to be issued.
The challenge to hand over control may very well create new business capabilities. We can imagine asking an insurance company to “take care of this for me” and handing over a key set of information (e.g. receipts for major purchases of items in your house) — and that there are legal assurances that the insurance company will do things properly.

​Guardianship & Delegation

While the theoretical concepts behind Delegation and Guardianship are becoming understood, there are no working examples in the wild that perform with a Digital Wallet. Manual processes are currently in use all over and range from highly formalized through to completely ad hoc and informal.

Experimentation and learning is needed to deeply understand the key requirements that will enable Guardianship and Delegation use cases with a Digital Wallet. Many questions need to be answered.

Early R&D and experimentation is needed to understand multiple things:

• Impact — what processes, people, and technology areas of your world (personal or business) will be impacted if you use digital approaches for Delegation or Guardianship.
• Minimal Viable Use — what is the most basic use? Do you need to wait for the technology and process standards to make forward progress? (The answer is no.)
• Security — allowing a painful process to be automated may be the wrong approach. Friction in current Delegation and Guardianship processes may be a very important feature. Automating the process could make taking over a more attractive prospect.

There are some key questions that need to be considered:

• When are we acting on someone’s behalf? As a Person? As an Organization?
• What mandate — legal or otherwise — are you operating under? How has the Person or Organization that you are acting for delegated their authority to you?
• How do you return control back to a Person?
• How do you take necessary control from a Person who is unwilling (e.g. under court order)? Further, can your Organization support such a requirement?

The following questions may help understand the current limitations of digital Guardianship (see 4.3.21. Manage Guardianship & Delegation Guardianship and Delegation) — particularly in relation to a Digital Wallet.

• How can a court order be imposed on a Wallet that is in control of a Person who requires Guardianship? Imagine an ill person who has, according to a court ruling, lost the capacity to manage their affairs. What control would allow for this — or should it ever be allowed?
• How can you be assured that a Guardian has fully relinquished control of a Digital Wallet? If they are controlling some historic keys, can they use some recovery mechanism to re-assert control?
• How can a Guardian hand over all or some control to a Dependent — or to another Guardian? The cryptographic control points get complicated quickly here.

In order for People or Organizations to use Digital Wallets for Delegation we need to understand how certain things can be done — in a standard way. Whether the standard is formal (de jure) or informal (de facto) research is needed to understand the following:

• What is being delegated and how does a service that supports delegation express the “capabilities” that can be delegated? Then how does a person get those capabilities assigned (delegated) to them?
• What approaches fit best into a Personal or Corporate Delegation case?

PERSONAL DELEGATION

• Can another party (Person or Organization) trust that I have delegated a particular capacity to someone else?
• How do I revoke something that I have personally delegated to someone else? What happens both technically and potentially legally — especially in cases where a delegated authority was in the process of being used when it was revoked?
• What liability is incurred by the delegate? Delegator? Acceptor of Delegated authority?

ENTERPRISE DELEGATION

Most activities that have legal consequence for Organizations are performed by People. These People are acting on behalf of an Organization, in a delegated capacity.

• Are Delegations supported on a policy level — ranging from internal policies to fully formalized legislated policies?

​Schemas & Overlays

The use of robust Schemas in the Digital Wallet ecosystem is crucial. Many factors related to Schemas need R&D:

• How do schemas get re-used in other Schemas? Imagine a “civic address” Schema that is robust and wanting to include it in a higher-level “record of known addresses” Schema.
• Where do we find the best Schema? Is there something like schema.org that can apply?
• How do we tell others that we support Credentials that have a particular Schema and how do we let others know what Schema our Credentials support? With a decentralized anchor system (e.g. Sovrin ledger for Sovrin; Ethereum for uPort), discovery is non-trivial.
• Are there registry approaches that can be applied to this new world of Digital Wallets?

Related to Schema is the emerging Overlays concept — where data are transformed for various purposes:

• Entry Overlay — allowing standardizing entry of information
• Informational & Label Overlays — allowing more human-readable viewing of attributes, including language translation
• Subset Overlay — allowing breaking out a subset of a larger dataset
• Sensitive Overlay — allowing specification of the sensitivity of particular elements
• Encoding Overlay — relates to information for encoding methods used on various attributes
• Format Overlay — provides data typing and formatting for better understanding of underlying data
• Conditional Overlay — allows logical presentation (ordering, hiding, conditional displays) of data
• Consent Overlay — provides consent-centric information about data

The Overlays effort requires substantial efforts to align it with existing data standards and to flesh out where there are truly unique capabilities. This early stage effort is commendable.

​2FA/UFA Use Cases

The tech industry is pushing towards not allowing usernames and passwords. The addition of second-factor authentication (2FA) or removal of usernames and passwords in favour of universal authentication factor (UAF) are both gaining momentum.

Most industry standard use (e.g. FIDO U2F/UAF, OpenID Connect) of authentication relies on either a hardware device (e.g. Yubico’s Yubikey) or an application that relies on a centralized service (e.g. Google Authenticator). Early ideas of using standardized approaches for the use of a Verifiable Credential in a 2FA manner warrant future R&D.

In particular:

• Can a Verifiable Credential or the underlying connection be used in an OpenID Connect context — as either a 2FA or UFA implementation?
• What would be needed to receive FIDO certification for the use of a Digital Wallet with Verifiable Credentials? As either U2F or UAF?
• How does a Digital Wallet and Verifiable Credential apply to FIDO2/WebAuthn?

​Backup & Recovery

Given the growing importance that our Digital Wallets will have, we need to be assured that they will remain simple enough to use regularly but are difficult to lose.

This means key management and recovery methods need to be robust, secure AND simple. Generally the security side of things doesn’t jive with that — you can pick two of those factors and usually need to sacrifice the other. That’s not necessarily true. R&D can help find ways to create protocols that allow us to know exactly which dimension we may be sacrificing.

The key concerns about your Digital Wallet are:

• Loss — when you have either lost the device that the Digital Wallet was on or access to the keys/seed that unlock it.
• Theft/Takeover — when your keys have been compromised and a nefarious actor has taken over your Wallet.

Social Engineering — The number one threat, in your author’s view, to the success of Digital Wallets in the long-term is ensuring that the processes for recovering a Digital Wallet are not suborned. If the processes are flawed the Digital Wallet becomes a target for takeover resulting in theft and/or destruction of the digital assets that are forming a larger and larger portion of our lives. R&D is needed to test out processes and then education is needed to ensure that people and organizations have simple and trusted approaches to keeping our Digital Wallets, and their backups, safe.

Wallet protection in general warrants further research, development, and education.

Further, the management of the secrets and keys that are critical to using, protecting, and recovering a Digital Wallet are crucial. An effort that is worth pursuing is Distributed Key Management System (DKMS).

​Vault-as-a-Service

In Vault Support we discussed that a Digital Wallet needs to be able to move information into and out of a digital Vault for safekeeping. The exact specifications of what a Vault is — beyond a simple place for backup — not well known. The idea is early enough in some ways that the term isn’t widely used in the self-sovereign realm — perhaps due to the focus on decentralization, while most Vault providers would be centralized in the beginning.

R&D is required to:

• Broadly define what a Vault is — what capabilities does a good Vault have? What does it specifically do and not do?
• Understand the processes and tooling needed to create digital equivalents of safe-deposit boxes? The physical protocols that block a bank employee from opening a customer’s safe deposit box are crucial.
• Specify the protocols and governance required where Vaults are in use.

​Break Glass In Case of Emergency

As we use our Digital Wallets more and more the information in them will grow. Much of that information is private — which is how we’d like it to stay, until we need to share it but can’t. Imagine an unconscious person whose phone contains information vital to ensuring first responders provide the best care possible. Protocols exist in many discrete places but few standards exist.

Story: Medical Nightmare Today, Security Nightmare Tomorrow Let’s imagine a scenario where I am traveling alone on business, in a foreign country. I had a cough that was bad enough to warrant going to the doctor. A day after landing in the foreign country I end up in medical distress and can’t figure out what is happening but I know it is severe so I head to an emergency room. By the time I arrive I am in dire straits — in and out of consciousness.
The medical staff don’t have access to the “break glass in case of emergency” and I am in enough trouble that I am not coherent enough to provide good information to the medical professionals.
They hit my iOS smartphone and see that Medical ID is enabled. It tells them I have a peanut allergy.
But the reaction isn’t at all consistent with a peanut allergy. They can’t see that I just received an antibiotic and that I regularly take other medication. If they could they may realize that I am having an adverse reaction to combining medications.
They don’t know who to reach out to.
So what do they do? Let’s hope I don’t need to find out.
BUT — what if my Digital Wallet could:
Tell them the details above they could provide far better medical care. (The problem is if that is openly available to anyone who opens my phone up I am freaked out — we can’t have total strangers accessing that much information.)Notify a designated family member that my medical details have been accessed — and have that logged somewhere (for abuse detection amongst other uses.)

There are a lot of questions and areas that need research here. Here are a few:

• Who are the authorities that get to break the glass?
• Can we create a system where credentialed authorities (e.g. certified first responders, doctors, nurses, hospital EHR systems) can access certain types of information without explicit consent?
• What happens when the authorities are not in our ecosystem (i.e. they don’t do VerCreds, etc.)?
• How do we ensure that this isn’t abused? What logging and auditability should our Digital Wallets perform? Should our Wallet notify a service when the “break glass” feature is invoked?

​Bare Minimum Portability

A Digital Wallet may contain information that is vastly different from what another Digital Wallet may contain. Expecting each Digital Wallet to have the same feature set as others is not realistic. However, in order to have some portability we need to understand what the bare minimum capabilities of each Digital Wallet provider is. Research is needed to understand the following:

• Wallet Capabilities — What information can a Digital Wallet manage for us and what limitations are there?
• Agent Compatibility — Can the Agents that operate in different Wallets understand each other? Are there mechanisms by which data can be shared directly or via transformation?
• Discovery — What can be done to profile the various types of Digital Wallet exist? Profiles can help people discover that there may be a Digital Wallet that could work better for them (e.g. imagine a Digital Wallet that focuses on the Diabetes Type II community).

This post is part of a 16-part series. This is the tenth post. For the first post click here, for the previous post click here, and for the next post click here.

Originally published at Continuum Loop Inc..