Where the W3C VCs meets the ISO 18013–5 mDL

Sponsored by

Organized by

Kaliya Young (kaliya@identitywoman.net)

​

Lucy Yang (lucy@identitywoman.net)

Agenda

• Project Introduction
• Project Findings
• Next Steps

Read the slides on your device: shorturl.at/iTVWX

Project Introduction

Read the slides on your device: shorturl.at/iTVWX

Background

Both VC and mDL standards are in active use by an growing number of organizations (e.g. governments, industry associations, enterprises), it is critical that stakeholders from both efforts look at where things are falling short in real-world implementations and how the next generation of the two standards can converge and align to provide better user experiences and support a more open and fairer vendor ecosystems.

Community conversations have taken place in multiple places such as the Internet Identity Workshop, Decentralized Identity Foundation, W3C CCG. To take these forward in a more coordinated and accelerated manner, Spruce, an active technology player that is building open source solutions using both VCs and mDL, reached out to us to sponsor a community project aiming to clearly articulate the gaps of the current standards and the needs of stakeholders, especially those working on/with both.

Read the slides on your device: shorturl.at/iTVWX

Project Goals

The project aims to help

• Enable a bigger ecosystem of players to take advantage of mobile driving licenses by making sure the VCs are a viable alternative for implementers to the ISO 18013–5 standard, and are compatible to the fullest extent possible of the outputs of ISO working groups
• Give both VC and mDL wallet vendors equal opportunity to compete and provide users with options by urging the open-up of privileged, internal APIs for all wallet vendors and developers.

Read the slides on your device: shorturl.at/iTVWX

Scope and Goals:

• Community Alignment: Define the near-term efforts/work needed to be done either respectively or collectively by the two communities to achieve the stated goals

​

Output: A clear communication to the technical/standard groups of the defined efforts/work with strong rationale and recommended paths forward

• Public Communications: Communicate to the broader audience, including policy makers, the defined efforts/work and its importance

Output: A letter that communicate why we are proposing the defined efforts, what support is needed from different stakeholders and why they should care

Read the slides on your device: shorturl.at/iTVWX

Methodology and Main Activities

• Synthesis of Existing Materials/Discussions

​

• Community Sessions (2-3):
• Introduction & Initial Input
• Sense-Making on Findings
• Feedback on Output

​

• Ongoing Community Input Collection through Collaborative Documents

​

• One-on-One Interviews (6-8) with Implementers/Implementer Groups

Read the slides on your device: shorturl.at/iTVWX

Initial Timeline

Read the slides on your device: shorturl.at/iTVWX

Project Findings

Read the slides on your device: shorturl.at/iTVWX

Initial Community Session

Summary Report: https://drive.google.com/file/d/1X3XCi05BxVxZzREwBIi8HMbjv6xgHkW8/view

​

Recognizing the Differences

Strong Desire for Alignment

It is well recognized that the two standards started out with very different goals, and were developed by two very different communities within different standards development organizations that had completely different processes. Now that they are meeting in the market and have overlapping use-cases and constituencies, it is important for us to recognize the differences first.

Implementers are keen to see greater alignment between these two standards so that they can meet real-world implementation needs and provide a seamless experience for end users.

Regarding how to get greater alignment, a strong consensus was that while it is theoretically possible to encapsulate one standard within the other, this was not a reasonable path forward.

Read the slides on your device: shorturl.at/iTVWX

Stakeholder Interviews - Preparation

​

​

• We need to look beyond just ISO 18013-5 mDL but also the related standards (18013-7 and 23220-3) in development.
• We not only need to get deep insights but also a diverse range of perspectives.
• We need a good chunk of our interview time understanding the challenges and implications of limited API access (particularly on iOS devices) for third-party wallet providers, which was not discussed much during the community session.

Read the slides on your device: shorturl.at/iTVWX

Stakeholder Interviews - Interviewees

• Manu Sporny, Founder and CEO of Digital Bazaar
• Brent Zundel, Principal Cryptography Engineer at Avast
• Tobias Looker, CTO at MATTR
• Oliver Terbu, Director Identity Standards at Spruce (together with Wayne Chang, CEO at Spruce)
• David Kelts (CIPT), Director of Product Development, Mobile ID at GET Group North America
• Christopher Goh, Lead Identity Architect, Department of Transport and Main Roads (Queensland Government)
• Torsten Lodderstedt, CTO at Yes.com

Read the slides on your device: shorturl.at/iTVWX

Stakeholder Interviews - Findings

• Current development of both and related standards as well as challenges and concerns
• Aspiration for more alignment and where the opportunities are
• Limited API access for third party developers and the implications of such limitations

Summary Report: https://docs.google.com/document/d/1YaMqEQzxt9GE35R2Sbmmh9Nncl8P44JxKEvPls8WXEc/edit?usp=sharing

Read the slides on your device: shorturl.at/iTVWX

Stakeholder Interviews - Findings

• Current development of both and related standards as well as challenges and concerns
• The ISO working groups have participants very much aware of and understanding the VC standards as well as sizable representation from card vendors who lack awareness of Verifiable Credentials and approach mDL as making smart cards on the phone.
• The work of Verifiable Credential Data Model v2.0 has just started not long ago. The W3C VC Working Group aims to address most of the glaring limitations of the v1.0, primarily around how VCs are signed and secured, and make the v2.0 easier to use for developers and implementers and a truly possible solution for interoperability.
• OpenID Connect Working Group is developing a new generation of OpenID protocols that can be used with different credential formats.
• Pitting against each other - Implementations of both standards are being held up by some because there exist general perceptions of the two standards pitting against each other. Some governments who are interested in implementing something hold back
• mDOC for general use can cause further confusion - Extending mDL to a general purpose credential format (mDOC) without further alignment with Verifiable Credentials may cause further market confusion and challenges for implementers.
• W3C VC too ambiguous and not complete - The W3C VC Data Model v1.0 has a lot of ambiguity and does not cover all necessary pieces required to built interoperable solutions. As a result, there is a general lack of confidence from governments in being able to implement VCs in consistent patterns that make interoperability possible.
• Technical challenges - Some signature schemes (e.g. BBS+, CL) used for VCs to enable selective disclosure are not hardware supported yet. CBOR, the binary encoded credential format used for compact JSON transmission in mDL is more fully supported on mobile and IoT devices at the present time. Internet use cases, where transmission speed is greater, are built on full JSON with base64 encoding. Developers find JSON easier to work with.

Read the slides on your device: shorturl.at/iTVWX

Stakeholder Interviews - Findings

• Aspiration for more alignment and where the opportunities are
• Utility of both recognized but need more simplicity - There are some solutions out there that are already doing or planning to do dual issuance of driver’s license information using both standards, indicating recognition and utility of both, but eventually the market will want to have a more simplified path of implementing something that leverages the merits of both and is interoperable.
• No structural changes needed - Even though there are many major differences between the two standards and its development processes, the implementation paths of both standards in general are quite compatible, which means alignment won’t require big structural changes of either.
• W3C VC v2.0 just started - Since the VC Data Model v2.0 work just kicked off, there is an opportunity for those who work on mDL to engage in the process and ensure that the next generation of the VC standard meets key requirements to be represented in the mDL standard. The W3C VC Working Group is open to suggestions and input.
• VC Interop Discussion in December - ISO/IEC JTC 1/SC 17 Working Group 10 is holding the fifth testing event of mDL in Brisbane, Australia in December 2022 participated by implementers from across the world. There, the first formal VC interoperability discussion will take place on three main topics: governance, interoperability, and execution and repeatable path.
• Official Liaison - As both the W3C VC Working Group and ISO/IEC JTC 1/SC 17 Working Groups are working on the next generation of the standards and there is momentum for better alignment, it may make sense to establish an official liaison between the groups, making it easier for some more members from each group to participate in the other’s activities.
• OpenID for VCs - There could be alignment through using existing issuance and presentation protocols, such as OpenID for Verifiable Credentials. There have been some positive conversations in the ISO Working Groups regarding adding OpenID for Verifiable Credentials as an option into the standards.
• Trust Model - There could be alignment on trust architecture/model. VC implementations could potentially leverage that infrastructure, while mDLs can potentially leverage decentralized trust architecture being explored by VC implementations.

Read the slides on your device: shorturl.at/iTVWX

Stakeholder Interviews - Findings

• Limited API access for third party developers and the implications of such limitations
• NFC emulation - The capability to “emulate NFC” is an API on mobile phones that is not accessible or usable by third party developers for the IOS platform.
• Wallet invocation:
• Based on the Mobile Document Request API specification, we can expect Apple wallet will be the only option for identity/mDL exchange given the fact that communication with the mDL app is proprietary.
• Mobile Document Request API is that it is ONLY for “mobile credentials” (mDL/mDOC), it means wallets that cannot receive other credentials, such as W3C Verifiable Credentials, and they won’t be able to present their credentials through those APIs to a web application.
• Given that iPhone doesn’t allow users to set up their default wallet to anything other than Apple wallet, even if there are third-party wallets that can provide other types of credentials, it is not as easy for users to invoke wallet as they do with their Apple wallet today.
• An additional concerning development. It is known that Apple has patents on mDL presentment of digital identity documents at security checkpoints and this is another thing that could be used to chill market competition.
• mDL verification - In order to build applications that decrypt mDLs correctly coming from iOS devices, one needs to get an Apple Developer Portal certificate for your server. Otherwise, the device will refuse to send the credential.
• Protected data storage - Third-party developers can only use the secure enclaves of iOS devices to store certain types of private keys but not any sensitive user data that may need a higher level of security.
• Biometric authentication - If you have a family sharing an iOS device, third-party wallets are only given a Yes/No signal if FaceID happened - however not a signal about if a particular person/face did the authentication. Without this type of signaling, it is not possible to know which family member/profile is being authenticated to use the wallet.

Read the slides on your device: shorturl.at/iTVWX

Next Steps

Read the slides on your device: shorturl.at/iTVWX

Deliverables

​

Initially defined outputs:

• A clear communication to the technical/standard groups of the defined efforts/work with strong rationale and recommended paths forward
• A letter to the public that communicate why we are proposing the defined efforts, what support is needed from different stakeholders and why they should care

Slightly re-defined outputs:

• A letter to the two technical/standard groups that include our recommendations of how to get further alignment based on the project findings
• Recognize the differences of two standardization processes and the need to respect the differences while finding common grounds
• Recognize there may not be one-fits-it-all for all of the use cases but there needs to be some unification and alignment for less market confusion and more simplicity
• Recommend concrete next steps and areas of alignment to explore by the two groups
• A op-ed style article that particularly addresses the API access issues identified, aiming to raise public awareness and attention of the policy-makers/regulators

Read the slides on your device: shorturl.at/iTVWX