[Discuss] Credential format coexistence

[timcappalli]

Surfaced as a core discussion topic on the first call (2023-10-04).

Do we expect W3C VCs and mdocs to coexist or one or the other (multi-format)? Are there others?

[OR13]

There are lots of digital credential formats... there is also a non-uniform adoption of formats, some formats tend to exist in specific industry verticals.

I don't really understand the question being asked, can it be rephrased?

[samuelgoto]

I don't really understand the question being asked, can it be rephrased?

I think one way to paraphrase this is "Can we ask the entirety of the ecosystem to converge into a single format, say, X?" (just as a hypothetical example, lets say, X = "mDocs").

I think, from where I stand, the answer is "obviously not", but it wasn't clear a few months ago and I still think that it is not clear to a lot of people right now.

For example, many browser vendors have already (formally? fairly?) opposed to blockchain-based architectures, which I think (for better or for worse?) is (incorrectly and unfortunately?) too directed connected to Verifiable Credentials. The association (or disassociation) of VCs with blockchain is a perception that has been hard to convey to browser vendors, so the sentiment that I've been getting so far has been to avoid anything associated with it (and hence the question "why can't everybody just use one format that is not associated with blockchain?").

I think I read the VCs specs enough to know that it is not tightly coupled with blockchain, so I think I'm of the opinion that it should be treated as a comparable format to ISO's, but not that many people are taking that time to investigate deeply and are forming a shallow opinion.

I believe that having (a handful: neither one nor a thousand) competing standards at this stage is useful for the user, much like image formats (e.g. PNG vs JPEG vs SVG) compete with each other: the developer and the user benefits from having multiple choices here.

So, finding ways to resolve this inaccuracy (or not?) at large (e.g. convincing browser vendors of the legitimacy of Verifiable Credentials) is what I think this issue should be tracking.

[OR13]

I think its fine for browser vendors to decline to implement support for "all formats", consider the export key interface:

• https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/exportKey

Should the browsers add import and export capabilities for multibase key formats?

Sometimes declining to implement support for things is key to protecting users.

https://www.w3.org/TR/design-principles/#priority-of-constituencies

[aniltj]

For example, many browser vendors have already (formally? fairly?) opposed to blockchain-based architectures, which I think (for better or for worse?) is (incorrectly and unfortunately?) too directed connected to Verifiable Credentials.

I find this comment a bit amusing as the PM w/in my organization who, back in the 2016-2017 time-frame, ended up holding the bag on conducting R&D to determine the viability and applicability of blockchain technology to our operational use. Fast forward two years (+ significant amount of treasure and attention) and the lessons turned out to be:

• 90%+ of organizations don't need a blockchain (they just need an understanding of hashchains, globally distributed cloud infrastructure etc.)
• Architecture and design cannot be hand-waved away (but often is in the race for market share!)
• There is no one-size-fits-all ledger data format, and standards for how to create the “data payload” that is written to a ledger are critical to interoperability across Blockchain implementations
• Immutability of records combined with encryption as a privacy tool is gated by the reality that encryption has a time to live which will eventually run out; this has real privacy and design implications
• Distributed key management is not a solved problem, but needs to be for scalable deployment
• Smart contracts are relatively immature and the contract execution environment must balance the security needs of the node with providing a richer (more error-prone) language

The message was not well received :-)

Nevertheless, we made a conscious decision back in 2018 or so to "make blockchain go away" in system design considerations by funding, supporting and championing the existence of a layer of abstraction that could be put in front of any legacy, distributed, web, or blockchain system that provided a standardized and open vocabulary for sharing information, a mechanism for assigning identifiers to entities and a set of open APIs to connect the pieces to ensure cross-platform, multi-vendor, multi-tech-stack interoperability -- which eventually matured to become W3C Verifiable Credentials and W3C Decentralized Identifiers.

So.. amused .. only because W3C VCDM/DIDs were (for us at least) a reaction and an alternative to blockchain!

[TallTed]

TL;DR: Coexist.

As we often say at OpenLink, "Horses for courses!"

As you'll see if you click that link, this basically means "what is suitable for one ... situation might be unsuitable for another". In other words, the best tool for job x (say, driving a nail) may not be the best tool for job y (say, driving a screw), and vice versa.

It's good to have a variety of tools to choose from. In this context, that includes credential formats, credential transmission protocols, credential content, etc. Large documents or processor-intensive handlers may generally not be well suited to use on mobile devices, while small documents or processor-light handlers may not be well suited to use on desktop devices. Neither of these should be considered as absolutes — only implementers and deployers are in a position to determine which is best for their use.

Local deployers might choose a technology stack that doesn't interoperate well with others. Generally speaking, I'm OK with that — IF they make the decision from an educated perspective, because they are locking themselves into a silo, and future options become more limited and expensive, especially if they then want to interoperate with other deployments, especially if those other deployments have also chosen low-interoperation stacks.

That said, interoperability between systems that choose large documents and processor-light handlers, or small documents and processor-intensive handlers, or any other permutation along competing axes, is strongly desirable if not absolutely mandatory for deployment-uptake.

Today, macOS, Windows, Linux, iOS, and Android are the most popular OS ... while Chrome, Safari, and Edge are the most popular browsers. These lists were significantly different a decade ago, and may well change again in the coming decade. Still, HTTP/S servers can easily support all HTML-based browsers with a single service providing a single set of documents which can be written generically to work in all those browsers on all those OS. I would say that such interoperability is one of the primary goals of all groups working on Verifiable Credentials, Identity Credentials, Credible Web, WebID, DID, and related technologies, under the umbrellas of W3C, IETF, DIF, and other organizations.

In other words... complementary coexistence is the best target.

[timcappalli]

The current proposal is credential format agnostic and only has protocol selection. Some protocols may support multiple formats.

@marcoscaceres @RByers any further comments on this one or should we close?

[timcappalli]

The current proposal is credential format agnostic and only has protocol selection. Some protocols may support multiple formats.

Closing issue.