Digital Wallet Standards
State of Digital Wallets – Part 11/16
This post, “Digital Wallet Standards,” 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.
***********************
The Digital Wallet ecosystem is in a very early stage where few digital wallet standards exist. As a result, neither informal (de facto) nor formal (de jure) standards exist in most areas. From the self-sovereign identity stack through Wallet portability, Credential offer/acceptance/storage/retrieval, and beyond.
Nonetheless, that doesn’t mean there aren’t areas where standardization efforts are warranted.
6.5.1. Protocol Evolution
As we review the digital wallet Standards requirements, it becomes evident that there is a need for Standards and open protocols. This will help prevent being locked into one solution and allow the benefits of learning to be shared more broadly within the community.
The three main stages of a protocol are:
- Isolated (or Proprietary). A singular implementation exists likely from a single closed or open-source project, and it has minor adoption in a very closed project or customer base
- Community. A more extensive community has begun using competing (Isolated) versions and realizes they need to converge on a standard protocol to grow as a community.
- Formal. A group of communities have put in the effort to formalize a broad protocol, usually through a standards body of some kind (e.g. IETF, OASIS)
Most useful protocols initially exist as an Isolated use capability that barely meets the definition of a “protocol.” Over time, as its value becomes evident, there is Community level adoption. Afterwards, If the protocol is deemed truly valuable, there is a push to create a Formal protocol.
6.5.1.1. Is It Worth The Effort?
In addition, at every shift, there is a substantial effort to lift a protocol to the next stage. The actions relate to:
- Technical Development Efforts. The technical community expends a significant amount of time working on the common and different use cases. Digging out the incompatibilities, breaking things down to the bare minimums, and much more.
- Social Capital Investment. The amount of social capital invested in pushing a protocol forward. This investment is crucial for the success of a protocol.
To gauge the effectiveness of these efforts, we must compare them against results. If the adoption does not increase with more formalization, consequently there may be no need for a broadly applicable protocol. Successful protocols drive adoption as they become more formal.
6.5.1.2. A Small Example – Sovrin Agent-to-Agent
In particular, the Hyperledger Indy/Sovrin community provides an excellent example of the evolution of a protocol.
In the Sovrin community, initial efforts to establish protocols that enable Agent-to-Agent communication was focused on two key libraries – both donated by Evernyn:
- libIndy – a low-level library focused on interactions with the ledger and low-level wallet storage capabilities.
- libVCX – a library that began handling Agent-to-Agent communications, Credentials management, and proof requests.
From the outset, these libraries were owned and operated by a single organization. Evernym then donated these libraries to the Sovrin Foundation. Afterward, the Sovrin Foundation to the Hyperledger Project, part of the Linux Foundation.
Subsequently, many additional projects began to work on Agents, proving that a Community Protocol had started to emerge:
- BC Government’s VONx project
- BYU early reference agent
- Streetcred
Indeed in time, the Sovrin A2A protocol will drive for a Formal Protocol that supports many underlying systems. The investment required to take disparate communities (e.g., DIF, uPort, Veres.one) must be worthwhile. The technical and social investment to do so is significant and will take time. Anyone basing business and short-term decisions on a Formal protocol should look for Community (or Isolated) protocols that meet their needs for now.
6.5.2. Overview of Digital Wallet Standards Landscape
The Digital Wallet space will require standards for interoperability. More importantly, an assurance that the Digital Wallets we use are fit for purpose and safe to use. Standards and certifications are woefully missing from the Digital Wallet landscape.
There are Standards required at many levels:
- Self-Sovereign Identity. While early efforts at defining “the stack” have begun, few actions are producing community standards, let alone formal ones.
- Key Management. The ability to manage (create, rotate, and recover) the keys to your Wallet is a crucial standard. Efforts are underway to bring the DKMS approach to a standards definition organization (e.g. OASIS), but these are early days.
- Portability. Proprietary approaches are emerging; there are no standards in play at the time of writing.
- Guardianship. Guardianship requires many different standards to ensure that digital wallets can support control broadly under the many contexts it applies.
- Delegation. The ability to delegate control to someone for a specific task (e.g. sign a contract with a value less than $10,000) requires understanding the data exchanges, information flows, and the standards applied.
- Certification. The value of information in our Digital Wallets is increasing. We need to trust the application providers. The parties we share information with also need the same assurances. There will be certification and accreditation regimes placed over time. Governments may provide a key role in mandating and guiding the certifications.
- Trust Hubs. No formal standards exist for managing the lists of “official” credential issuers, but informal efforts have begun.
Some areas already have standards in place that our Digital Wallets can work towards:
- Authentication. The FIDO Alliance Standards (e.g. U2F, UAF, and FIDO2) and OpenID Connect, W3C (WebAuthn) provide frameworks that our Digital Wallets can use to integrate and support.
Overall for any Organization that expects formality and rigid standards, the Digital Wallet ecosystem is way too early to consider.
6.5.3. Assurance Levels
Determining assurance levels requires understanding the difference between Identity Assurance (a measure of certainty that an Individual, Organization, or device is who or what it claims to be) and Credential Assurance (how can we be sure it is them once we have identified them?).
| Identity Assurance | A measure of certainty that an Individual, Organization or device is who or what it claims to be. |
| TBS |
| Credential Assurance | The assurance that an Individual, Organization or device has maintained control over what has been entrusted to them (e.g., key, token, document, identifier) and that the Credential has not been compromised (e.g., tampered with, modified). |
| TBS |
Two significant pieces of guidance apply for this report – aimed globally but, where required, focused on Canadian and US particulars.
- NIST 800-63 – US Standard provides in-depth technical details in IAL and AAL and will be most helpful for security and IT analysis.
- TBS Canada – provides a more business-focused and citizen-centric approach to IAL and AAL. Business users will likely get more from the information. It gives more of the “why” than the “what and how” NIST 800-63 provides.
The TBS and the draft PCTF provide much more helpful input at a business level, while the NIST standard is technically detailed.
6.5.3.1. Identity Assurance Levels
The purpose of Identity Assurance Levels is to understand the degree of confidence we can have in the identity verification processes that are in place. Accurate identification of a person is crucial to proceeding with future transactions involving their identity. This is what Identity Assurance is all about. In other words, can we trust that a person has been proven to be who they claim to be, and to what extent?
| Identity Assurance Level | The level of confidence that an Individual, Organization or device is who or what it claims to be. |
| TBS |
For example, we’ll look at the TBS and NIST Identity Assurance Levels for comparison. As mentioned earlier, they take different approaches, with TBS being more descriptive for business use and NIST being more technical.
TBS Identity Assurance Levels
| Level | Description |
| 4 | Very high confidence is required that an individual is who they claim to be. A compromise could reasonably be expected to cause serious to catastrophic harm. |
| 3 | High confidence is required that an individual is who they claim to be. A compromise could reasonably be expected to cause moderate to serious harm. |
| 2 | Some confidence is required that an individual is who they claim to be A compromise could reasonably be expected to cause minimal to moderate harm. |
| 1 | Little confidence is required that an individual is who they claim to be A compromise could reasonably be expected to cause minimal harm. |
NIST 800-63 Identity Assurance Levels:
- IAL1: At IAL1, attributes, if any, are self-asserted or should be treated as self-asserted.
- IAL2: At IAL2 requires either remote or in-person identity proofing. IAL2 requires identifying attributes to have been verified in person or remotely using, at a minimum, the procedures given in SP 800-63A.
- IAL3: At IAL3 requires in-person identity proofing. Identifying attributes must be verified by an authorized CSP representative through examination of physical documentation as described in SP 800-63A.
6.5.3.2. Credential Assurance Levels
| Credential Assurance Level | The confidence level that an Individual, Organization or device has maintained control over what has been entrusted to them (e.g., key, token, document, identifier) and that the Credential has not been compromised (e.g., tampered with, corrupted, modified). |
| TBS |
TBS provides a 4-level system for classifying Credential Assurance Levels. Its plain language speaks of compromise impacts, which helps business analysis.
TBS Credential Assurance Levels
| Level | Description |
| 4 | Very high confidence is required that an Individual has maintained control over a Credential that has been entrusted to them and that the Credential has not been compromised. A compromise could cause serious to catastrophic harm. |
| 3 | High confidence is required that an Individual has maintained control over a Credential that has been entrusted to them and that the Credential has not been compromised. A compromise could cause moderate to serious harm. |
| 2 | Some confidence is required that an Individual has maintained control over a Credential that has been entrusted to them and that the Credential has not been compromised. A compromise could cause minimal to moderate harm. |
| 1 | Little confidence is required that an Individual has maintained control over a Credential that has been entrusted to them and that the Credential has not been compromised. A compromise could cause nil to minimal harm. |
NIST provides an equivalent “Authenticator” (vice “Credential”) Assurance Level breakdown – using only three levels.
NIST 800-63 Authenticator Assurance Levels:
- AAL1: AAL1 provides some assurance that the claimant controls an authenticator registered to the subscriber. AAL1 requires single-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator(s) through a secure authentication protocol.
- AAL2: AAL2 provides high confidence that the claimant controls authenticator(s) registered to the subscriber. A secure authentication protocol requires proof of possession and control of two different authentication factors. Approved cryptographic techniques are necessary at AAL2 and above.
- AAL3: AAL3 provides very high confidence that the claimant controls authenticator(s) registered to the subscriber. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 is like AAL2 but requires a “hard” cryptographic authenticator that provides verifier impersonation resistance.
6.5.4. PCTF
Canada has provided deep leadership in the Digital Identity space for over a decade. With its unique government structure and open approach, the world has been looking to Canada for ongoing leadership in identity. That leadership position includes an essential piece of work that impacts Digital Wallets: the Pan-Canadian Trust Framework.
The private industry group, DIACC, is working with the government’s Identity Management Steering Committee (IMSC) to create the PCTF. The PCTF aims to create a framework that allows citizens and businesses to rely upon Digital Identity to build a more robust economy and country.
At the time of writing, DIACC had issued a draft PCTF Overview with requests for comment, and the IMSC provided a draft PCTF. In time, we hope the two groups merge their capabilities into a comprehensive PCTF.
Recent input and discussion from the Canadian government around digital identity provide valuable insights into how innovators can leverage the processes and infrastructure supporting identity in a digital wallet.
The hope is that the PCTF will provide leadership and guidance in many areas that are directly relevant to the Digital Wallet space:
- Define Trusted Processes that innovators can use as building blocks to create prosperous and secure systems.
- When designing a digital wallet, it is essential to consider how much trust to place in the processes and artifacts used to create the credentials it will hold. A Vectors of Trust approach can help understand this.
- Link efforts to policy, regulation, and legislation – so we can understand the rationale behind certain decisions.
- Provide normalization so we can understand terms consistently across various sectors and ecosystems
An industry group is currently curating the PCTF with private and public partners; this group should be able to produce a coherent plan for Canada.
6.5.5. Digital Wallet Portability
To ensure that Digital Wallets are as helpful as possible, they should allow for portability – meaning that you can change your Wallet provider with minimal effort and not lose information. Perhaps more challenging to define now is the loss of capability that may occur if you change Wallets.
If you have multiple Agents working in your Wallet, such as a financial monitor Agent and a health services Agent, what happens when you change Wallets? Does your current set of Agents work in that new Wallet? Are they functionally equivalent – or have you just broken things?
Portability in Digital Wallets will initially be similar to the portability that social media companies currently support. While some groups think that data portability is valuable, there is a flaw in how things work. You can access the raw data if you download your Facebook data, but what can you do with it? You can’t just upload it to another site – there is nothing useful to it unless you are a data analyst. “Data Portability” of a Digital Wallet will be similar – but the hopes are that there will be a bare minimum of capabilities that Digital Wallets can do concerning Portability (see section 6.4.12. Bare Minimum Portability for more detail).
***********************
This post, “Digital Wallet Standards,” 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!
