Further Research and Effort

State of Digital Wallets – Part 10/16

This post, “Further Research and Effort,” is an excerpt from a report entitled The Current and Future State of Digital Wallets, which is being shared here as a 16-part series. Download a copy of the report. Read a complete summary.

***********************

At this point, we are well aware that digital wallets are still in their early stages. Therefore, it is necessary to continue research, development, education and other actions to help improve the digital wallet ecosystem. A few concepts are put forth here for exploration.

​​Trust Hubs

To trust the credentials that end up in a Wallet, we need to confirm the Issuer’s authority is reliable. If we cannot trust the Issuer, someone can create a credential that appears genuine (i.e. the Credentials validate cryptographically and have data that make sense) but is fake. By using a Trust Registry, we can avoid such situations.

We’ll get to a more detailed description of a Trust Registry. Still, in this case, a law enforcement officer’s Digital Wallet only needs to know the list of official DIDs from each authority it recognizes – a concise list that doesn’t change.

To get lists of the Issuers (e.g. the actual DMV), a Wallet will need to be aware of the concept of Trust Registries (Trust Hubs).

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

Who Do You Trust?

A Wallet will need to know which Registries are to be trusted. Over time the community will need to have Trust Registries 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 communities, associations, etc. that exist through either a formal (similar to legislative) or de facto authority will create Trust Hubs. Examples include 
  • registry of licenced doctors, banks and credit unions, industry associations, local business improvement areas/chambers of commerce, etc.
• Informal Authority. A Trust Hub should be able to exist without formal authority. 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 power from the larger community that “lends” its reputation.

Web of Trust

A Wallet’s Owner(s) needs 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 by confirming with the province/state corporate registry.
• To verify that a given insurance certificate is valid, we check it against a list of insurance companies maintained in a trust registry. This list, anchored to various province/state/federal registries, acts as the “source of truth” for insurance company establishment.
• 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 ensure our contractor is licensed to operate. The municipality maintains a trust registry of businesses. We back-check the city licence bureau against their master list of Issuer DIDs. The city has a master DID that signed said registry and points back to its legislative source of authority and the master list of municipalities for that jurisdiction.

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.

​Credential Lifecycle

When a Credential is issued, the Issuer can’t just forget that it was sent out – at least not in most cases. The Issuer must take the credential’s lifecycle into account, and there are many different types of credential lifecycles:

• 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 the validity of the signature, and they forget about it.
• Revocable Credentials. Some are issued once and 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 revise for various reasons. An example is a valid driver’s licence that requires 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 initial Credential may need to have the ability to understand that the Issuer replaced the revoked credential.
• Expiring Credentials. While it is common for credentials to have time limits, there is little standardization in the Verifiable Credential realm about how this works. Additionally, it is not uncommon to issue a new credential before the expiration date of an existing credential, which may create a scenario where both credentials are valid (e.g. new credit card received before the old card expires).

Each of these lifecycles – and there are likely more – needs further R&D and education to ensure that People and Organizations understand how the lifecycles work in detail. The subtle differences in these lifecycles are crucial to getting it 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 sign an app (Bubba’s Wallet) digitally – 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 the developer holds – so we can know that our Digital Wallet is safe to use. The groups (e.g. banks, government) that we share information with and get information from need to know that our wallet is trustworthy.

Digital signatures of an app are acceptable for general use. But a Digital Wallet will 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 ensure, to some high level, that it isn’t doing nefarious (or stupid) things. That’s going to cost money – a fair bit.

Is it fair to ask Bubba, the 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 must go beyond the cosmetics and provide real-time “not tampered with” certification. Many areas 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? The operating system providers, hardware manufacturers, banking networks and telecommunication providers will likely need to step in. They provide infrastructure and business services that will require highly trusted Digital Wallet technology.
• When do certification costs get high enough to stifle the innovation 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 consideration)
• How do we provide a digital “seal of approval” and know that the Wallet’s software hasn’t been tampered with?

​Rendering

Credentials are essentially just a collection of attributes called claims. The visual rendering of such simple data has primarily provided a tabular list of key names and values.

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

Rendering is the act of translating digital data into something visual – taking that tabular data and making it look like something regular people can make sense of. Rendering means taking some attributes and 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 visible in 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 proof of the signed data?

​No Device/No Smartphone

The majority of Digital Wallet activity is best suited for Smartphones, leaving out any people who don’t have access to a Smartphone.  As a result, 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.

​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 and range from highly formalized to completely ad hoc and informal.

Research and experimentation are needed to comprehensively understand the key requirements that will enable use cases with a Digital Wallet. Many questions remain unanswered at this time. Therefore early R&D is required to gain answers to these questions.

• Impact. ​Guardianship & Delegation will impact what processes, people, and technology areas of your world (personal or business) 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 critical feature. Automating the process could make taking over a more attractive prospect.

Therefore some key questions need consideration:

• When are we acting on someone’s behalf? As a Person? As an Organization?
• What mandate are you operating under, legally or otherwise? How has the person or organization you act for delegated authority to you?
• How do you return control 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 concerning 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 lost the capacity to manage their affairs according to a court ruling. What power would allow for this – or should it ever be allowed?
• How can you be assured that a Guardian has relinquished control of a Digital Wallet? Can they use some recovery mechanism to reassert control if they control some historic keys?
• How can a Guardian hand over all or some control to a Dependent or another Guardian? The cryptographic control points get complicated quickly here.

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 are the tasks delegated? And how does a service that supports delegation express the “capabilities” that People or Organizations can delegate? 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 rescind something that I have delegated to another person? What are the technical and legal implications of doing so – particularly in cases where the delegated authority was in use when I revoked it?
• What liability is incurred by the delegate? Delegator? The acceptor of Delegated authority?

Enterprise Delegation

People perform most activities that have legal consequences for Organizations. These People are acting on behalf of an Organization in a delegated capacity.

• Are Delegations supported on a policy level – from internal 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 then 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 with 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.
• Can registry approaches be applied to this new world of Digital Wallets?

Related to Schema is the emerging Overlays concept – transforming data and providing additional context or functionality:

• 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 a 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 the removal of usernames and passwords in favour of a universal authentication factor (UAF) is gaining momentum.

Most industry-standard use of authentication (e.g. FIDO U2F/UAF, OpenID Connect) 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 using 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 using 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 of our Digital Wallets, we need assurance that they will remain simple enough to use regularly but are difficult to lose.

The growing importance means vital management and recovery methods must be robust, secure, and straightforward. 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. However, that’s not necessarily true. R&D can help find ways to create protocols that allow us to know which dimension we may be sacrificing.

The critical 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 are compromised and a nefarious actor has taken over your Wallet.

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 is crucial. An effort that is worth pursuing is a 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 a Vault – beyond a simple place for backup – are 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, most Vault providers are still centralized initially.

Subsequently, R&D to execute: 

• Broadly define a Vault – 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, 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.

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

• 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 prevent abuse? What logging and audit ability should our Digital Wallets perform? Should our Wallet notify a service when invoked the “break glass” feature?

​Bare Minimum Portability

A Digital Wallet may contain information vastly different from what another Digital Wallet may hold. Expecting each Digital Wallet to have the same feature set as others is unrealistic. However, to have some portability, we need to understand the bare minimum capabilities of each Digital Wallet provider. Research is necessary 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 is needed to profile the various types of Digital wallets? 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, “Further Research and Effort,” is an excerpt from a report entitled The Current and Future State of Digital Wallets, which is being shared here as a 16-part series. Download a copy of the report. Read a complete summary.

Visit our blog, follow us on social media, and subscribe to our newsletter to stay up to date and learn more!