The Battle for the [Verifiable Credentials] Brand

Found this during my weekend reading on Anil's personal blog. Thought
it was relevant considering the discussion late last year [1] in the
"big tent" discussion in the Verifiable Credentials WG as well as how
the Canadian's are now using the term "digital credentials" as the
general term to relate to the "big tent" of technologies:

https://www.cyberforge.com/battle-for-the-brand/

Full text below:
-----------------------------------------------------------------
Battle for the Brand

The W3C Verifiable Credentials standard enables secure, privacy
respecting capabilities to allow individuals control over their
personal data. The battle to appropriate this brand in order to market
and sell non-standard-conforming products has begun.

Decentralized identity technologies based on W3C Verifiable
Credentials (VC) are gaining global support due to their power and
flexibility in meeting the needs of the open web and the public and
private sector enterprise in a manner that is secure, privacy
respecting and globally interoperable.

This in turn is generating allergic reactions from incumbent players
who have often played the gatekeeper role in this domain, who after
ignoring and laughing at the work for the longest time, are now
becoming concerned about its success, traction and global adoption.

Their reactions are manifesting themselves in some specific ways:

1. Seeking to reopen settled consensus decisions reached over many
working group sessions that resulted in the current v1.1 of the W3C VC
standard, that will break existing secure, privacy respecting and
standards compliant implementations.

2. Slow down or divert, using a variety of process games, any new work
to update and enhance the current v1.1 standard into other venues
where the incumbents are the gatekeepers

3. Trying to appropriate the term “Verifiable Credentials” to apply to
specifications, protocols and standards that do not share the same
security and privacy properties as W3C Verifiable Credentials

The first two are critical to understand and push back on, within the
standards development process itself, by public and private sector
organizations who value the existence of a truly competitive ecosystem
built on a foundation of interoperability.

The last affects consumers and organizations in their understanding,
acceptance and adoption of this technology, so for the purposes of
this article, I want to put the focus on the third tactic.

Learning from history

This tactic is not new, and I remember being on the receiving end of
the full treatment during the Service Oriented Architecture (SOA)
phase of my professional life, when what SOA meant from a standard
based and architecturally sound implementation got diluted and
conflated with implementing the Enterprise Service Bus and Business
Orchestration Servers being peddled by product vendors.

But a direct and more relevant example is to look at what happened
with another technology that also held the promise of individual
control and agency as it sought to move beyond v1.0.

"""
All the hard-fought compromises on the mailing list, in meetings, in
special design committees, and in back channels resulted in a
specification that fails to deliver its two main goals – security and
interoperability. In fact, one of the compromises was to rename it
from a protocol to a framework, and another to add a disclaimer that
warns that the specification is unlike to produce interoperable
implementations. [...]

The resulting specification is a designed-by-committee patchwork of
compromises that serves mostly the enterprise. To be accurate, it
doesn’t actually give the enterprise all of what they asked for
directly, but it does provide for practically unlimited extensibility.
It is this extensibility and required flexibility that destroyed the
protocol. With very little effort, pretty much anything can be called
OAuth 2.0 compliant.

-- OAuth 2.0 and the Road to Hell by Eran Hammer
"""

The same tactic, to dilute and expand the definition of what is meant
by “Verifiable Credentials” to mean everything and nothing, so that
the incumbents can claim support and compliance to the W3C VC standard
in their products, is exactly what is happening again!

Verifiable Credential ≠ Digitally signed document

Verifiable Credentials means something that is fully conformant to the
W3C Verifiable Credentials standard, and it IS NOT a generic term to
describe any and all digitally signed documents and attestations!

These. Are. Not. Verifiable. Credentials:

* A credential that is conformant to the ISO 18013-5 Mobile Driver’s
License (mDL) Standard
* A credential that uses the ISO mdoc (mobile document) specification
* A digitally signed OIDC, SAML or OAUTH token
* A credential that uses Authentic Chained Data Containers (ACDC)

All of the above are examples of standards and specifications that
result in some manner of a digitally signed attestation, similar to
how Verifiable Credentials also uses digital signatures. And that is
where the similarity ends.

Anyone seeking to apply the term Verifiable Credentials to refer to
the above or any other standard/specification is simply referring to a
pretender to the throne seeking to wrap themselves in the royal purple
that is the security and privacy aspects of the only, legitimate W3C
Verifiable Credentials Standard!

Received on Monday, 23 January 2023 15:00:36 UTC