- From: steve capell <steve.capell@gmail.com>
- Date: Tue, 24 Jan 2023 08:18:22 +1100
- To: "Michael Herman (Trusted Digital Web)" <mwherman@parallelspace.net>
- Cc: Manu Sporny <msporny@digitalbazaar.com>, W3C Credentials CG <public-credentials@w3.org>, "Drummond Reed (Gen) (drummond.reed@gendigital.com)" <drummond.reed@gendigital.com>, "Daniel Hardman (daniel.hardman@gmail.com)" <daniel.hardman@gmail.com>, "Anil John (anil.john@hq.dhs.gov)" <anil.john@hq.dhs.gov>
- Message-ID: <CAEMprtJVbHNOkAVLPhg0MO5YqrPzGAfDLsENmwJumEL19XAnPA@mail.gmail.com>
Forgive this little stream of consciousness please.. I'd expect that uptake will sort out competition. Simplicity usually wins the day. I note the "grand unified theory of trust" presentation that puts a lot of weight behind KERI. It could well be that I've simply not understood it properly but it seems to me that KERI adds a lot of complexity for very little value. The complexity is rooted in the idea that portability of decentralised identifiers across ledgers (or other implementations) is fundamentally important and so everyone will want that. I dont understand why. Feels like maybe there is confusion between identity (something permanent and immutable - embedded in my DNA) vs identifier (something transient, context specific, use it and throw it away if you want). Trust is about linking identifiers to identity. I can do that with hundreds of different identifiers, each with different lifespans and anchored to different technologies. Why would I care whether a specific identifier is portable? Just mint another one if, for some reason, I really care about the technology anchor. Until I can understand a clear rationale for complexity of things like KERI I'll be sticking to the simplicity of did:web and it's like... Kind regards, Steve On Tue, 24 Jan 2023 at 02:58, Michael Herman (Trusted Digital Web) < mwherman@parallelspace.net> wrote: > There's a couple of important additional messages and developments to note > here: > > 1. VCs have competition. There is now a competitive marketplace where VCs > need to find their niche (and I do mean niche). I describe it here: > https://github.com/w3c/vc-data-model/issues/982#issuecomment-1385566199 > > 2. The great leveler will be some version of the Trusted Spanning Layer > Framework ...and the likely common ground/leading contender across all the > decentralized systems technologies appears to be DID Communications > ...linked to defining a DIDComm/HTTP-based Trust Spanning Layer Framework. > I talk about it here: > https://www.youtube.com/watch?v=o0GjoDTfxZw&list=PLU-rWqHm5p44AsU5GLsc1bHC7P8zolAAf&index=3&t=0s > > 3. The same is happening with DIDs. There's now a big tent movement in > TOIP where traditional DIDs are now a niche. Ask Drummond for his slide > from a TOIP call last week. > > 4. Lastly, the Grand Unified Trust Theory: https://bit.ly/3BHxUCb > > Best regards, > Michael Herman > Web 7.0 is a unified software and hardware ecosystem for building > resilient, trusted, decentralized systems using decentralized identifiers, > DIDComm agents, and verifiable credentials. > Take what you need; leave the rest. > > -----Original Message----- > From: Manu Sporny <msporny@digitalbazaar.com> > Sent: Monday, January 23, 2023 9:00 AM > To: W3C Credentials CG <public-credentials@w3.org> > Subject: 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! > > -- Steve Capell
Received on Monday, 23 January 2023 21:18:47 UTC