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 eleventh post. For the first post click here, for the previous post click here, and for the next post click here.


The Digital Wallet ecosystem is in a very early stage where few, if any, standards exist. 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.

That doesn’t mean there aren’t areas where standardization efforts are warranted.

​6.5.1.​ Protocol Evolution

As we look at the requirement for Standards (see previous section) it is clear that there is a need for Standards and open protocols to ensure that we’re not being locked in to something and to share the benefits of learning broadly in 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 larger community has begun to use some competing (Isolated) versions and realizes that they need to converge on a common protocol in order 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 start off as an Isolated use capability that can barely be described as a “protocol”. Over time, as it shows value there is a Community level adoption. If the protocol is truly valuable there is a push to create a Formal protocol.

​6.5.1.1.​ Is It Worth The Effort?

At every shift there is a substantial effort to lift a protocol to the next stage. The efforts relate to:

  • Technical Development Efforts – the technical community expends a large amount of time working on the common and different use cases, digging out the incompatibilities, breaking thing down to the bare minimums, and much more
  • Social Capital Investment – the amount of social capital that is invested to push a protocol forward. This investment is crucial for success of a protocol

These efforts need to be gauged against results. If adoption doesn’t grow with more formalization there may be no need for a broadly applicable protocol. The successful protocols drive adoption as they get more and more formal.

​6.5.1.2.​ A Small Example – Sovrin Agent-to-Agent

The Hyperledger Indy/Sovrin community provides a good example of the evolution of a protocol.

In the Sovrin community, initial efforts to establish protocols that enable Agent-to-Agent communication were 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, Credential management, and proof requests.

Initially these libraries were completely proprietary, owned by a single company. These libraries were donated by Evernym to the Sovrin Foundation and then by 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 begun to emerge:

  • BC Government’s VONx project
  • BYU early reference agent
  • Streetcred

In time the Sovrin A2A protocol will help drive for a Formal Protocol that supports a multitude of underlying systems. The investment required to take disparate communities (e.g. DIF, uPort, and Veres.one) need to be worthwhile though. The technical and social investment to do so are quite large and it 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 Standards Landscape

The Digital Wallet space is going to require standards for interoperability and 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 at this time.

Standards are required at many levels:

  • Self Sovereign Identity – while early efforts at defining “the stack” have begun, there are few if any efforts that are producing community standards, let alone formal standards.
  • Key Management – the ability to manage (create, rotate, and recover) the keys to your Wallet are 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 – there are no standards in play at time of writing, though proprietary approaches are emerging.
  • Guardianship – guardianship is going to require many different standards to ensure that it can be supported broadly under the many contexts where it applies.  
  • Delegation – the ability to either delegate control to someone for a specific task (e.g. sign contract with value less than $10,000) requires understanding of the data exchanges, information flows, and the standards that are applied.
  • Certification – the value of information in our Digital Wallets is increasing. We need to know that we can trust the application providers. The parties we share information with also need the same assurances. Over time there will be certification and accreditation regimes placed. Governments may provide a key role in mandating and guiding the certifications that are required.
  • 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 (U2F, UAF, and FIDO2) and OpenID Connect, W3C (WebAuthn), and others provide frameworks that our Digital Wallets can 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 an understanding of 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 him or her (e.g., key, token, document, identifier) and that the Credential has not been compromised (e.g., tampered with, modified).
TBS

Two major pieces of guidance apply for the purposes of this report – aimed globally but where required, focused on Canadian and US particulars.

  • NIST 800-63 – US Standard provides deep 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 provides more of the “why” than the “what and how” that NIST 800-63 provides.

At a business level the TBS and the draft PCTF provide much more useful input, while the NIST standard is extremely technically detailed.

​6.5.3.1.​ Identity Assurance Levels

Identity Assurance Levels allow us to understand what assurance we can place in the Identity Proofing processes that are in place. Understanding that a Person has been correctly identified underpins all future identity-related transactions. This process is what Identity Assurance is all about. Basically, can we trust that a Person has been proved to be who they say they are – to a certain level of assurance.

Identity Assurance Level

The level of confidence that an Individual, Organization or device is who or what it claims to be.
TBS

As an 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

LevelDescription
4Very high confidence required that an Individual is who he or she claims to beCompromise could reasonably be expected to cause serious to catastrophic harm
3High confidence required that an Individual is who he or she claims to beCompromise could reasonably be expected to cause moderate to serious harm
2Some confidence required that an Individual is who he or she claims to beCompromise could reasonably be expected to cause minimal to moderate harm
1Little confidence required that an Individual is who he or she claims to beCompromise could reasonably be expected to cause nil to 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, either remote or in-person identity proofing is required. 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, in-person identity proofing is required. 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 level of confidence that an Individual, Organization or device has maintained control over what has been entrusted to him or her (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. It’s plain language speaks of compromise impacts, which helps business analysis.

TBS Credential Assurance Levels

LevelDescription
4Very high confidence required that an Individual has maintained control over a Credential that has been entrusted to him or her and that the Credential has not been compromised.Compromise could reasonably be expected to cause serious to catastrophic harm.
3High confidence required that an Individual has maintained control over a Credential that has been entrusted to him or her and that the Credential has not been compromised.Compromise could reasonably be expected to cause moderate to serious harm.
2Some confidence required that an Individual has maintained control over a Credential that has been entrusted to him or her and that the Credential has not been compromised.Compromise could reasonably be expected to cause minimal to moderate harm.
1Little confidence required that an Individual has maintained control over a Credential that has been entrusted to him or her and that the Credential has not been compromised.Compromise could reasonably be expected to cause nil to minimal harm.

NIST provides an equivalent “Authenticator” (vice “Credential”) Assurance Level breakdown – using only 3 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. Proof of possession and control of two different authentication factors is required through a secure authentication protocol. Approved cryptographic techniques are required 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 also requires a “hard” cryptographic authenticator that provides verifier impersonation resistance.

​6.5.4.​ PCTF

Canada has been providing deep leadership in the Digital Identity space for over a decade. With its unique government structure and open approach, the world has rightfully been looking to Canada for ongoing leadership in identity. That leadership position includes a key piece of work that impacts Digital Wallets: the Pan-Canadian Trust Framework.

Private industry group, DIACC (www.diacc.ca) is working together with government’s Identity Management Steering Committee (IMSC) to create the PCTF. The goal of the PCTF is to create a framework that allows citizens and business to rely upon Digital Identity to build a stronger 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 that the two groups merge their capabilities into a comprehensive PCTF.

Recent input and discussion documents from Canadian government provide deep guidance about how the underlying processes and artifacts of identity can be used 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 can be used as building blocks to create rich and secure systems
  • look to use a Vectors of Trust approach to understand how much assurance we can place on the processes and artifacts that are used to create the Credentials that our Digital Wallet will hold
  • link efforts to policy, regulation, and legislation – so we know why certain things are being done
  • provide normalization so we can understand terms consistently across various sectors and ecosystems

The PCTF is currently being curated by an industry group that partners private and public resources. That venue should be able to produce a coherent plan for Canada.

​6.5.5.​ Portability

In order to ensure that Digital Wallets are as useful as possible, they should allow for portability – meaning that you can change your Wallet provider with minimal effort and not lose information. Perhaps more difficult to define at this time is that 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 actually work. If you download your Facebook data you have access to the raw 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 with respect to Portability (see section 6.4.12. Bare Minimum Portability for more detail).


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