RE: credential definitions, credential manifests, BBS+, etc

The discussion should focus on answering the questions:

  *   "Who will use cred defs for which purposes?" - after all, if nobody uses them, who would care?
  *   "What do cred defs require to be fit to serve such purposes?". As Daniel pointed out, there may be different purposes to serve, in different contexts. I suggest that within the various contexts that have an interest in having cred defs, they step forward and clarify their purposes so that we can discuss how to define, perhaps later also standardize, the structure of cred defs so that they help serve such purposes.
Some of this is mentioned in the document on Decentralized SSI Governance<https://www.researchgate.net/publication/348325716_Decentralized_SSI_Governance_the_missing_link_in_automating_business_decisions>.

Rieks

From: Hardman, Daniel <Daniel.Hardman@sicpa.com>
Sent: zaterdag 30 januari 2021 01:18
To: W3C CCG <public-credentials@w3.org>
Subject: credential definitions, credential manifests, BBS+, etc

(For those who have never heard of/ understood the thing that Hyperledger Indy calls a "credential definition", let me first define the term. A credential definition is a public statement by an issuer, announcing to the world, "I plan to issue credentials that match schema X. I will sign them with key(s) Y[0]..Y[n], and I will revoke them with the following mechanism: Z." Because cred defs are not discussed in the VC spec, they have been viewed as a symptom of unnecessary divergence from standards - although they don't violate the VC spec in any way, either. Indy stores cred defs on a ledger, but this is not an essential property, just a convenience.)

When Tobias first described Mattr's approach to BBS+ signatures, one of my takeaways was that this changed the Indy mechanism of cred defs in two wonderful ways:

1. It eliminated the need for lots of keys (only one key, Y, needs to be declared as a credential signing key, instead of a set of keys, Y[0]..Y[n])
2. It made it possible to store a cred def somewhere other than a ledger

I was very happy about this.

However, I have since heard several smart people summarize the breakthrough as: "We don't need credential definitions at all. You just use the assertionMethod key in your DID doc to sign credentials, and that's all you need." I believe this is oversimplifying in a way that loses something important, so I wanted to open a conversation about it. In doing so, I am NOT arguing that cred defs should be required for all VCs, and I am also NOT arguing that credential defs should live on a ledger (I love that Mattr's removed that requirement). I am instead suggesting that they are highly desirable for *some* VCs no matter what the signature format of the VCs is, and that they should become a welcomed part of the ecosystem for all of us (without any introduction of other Indy-isms).

VCs CAN absolutely be issued ad-hoc. That is, any controller of a DID can build a credential on the spur of the moment, inventing (or referencing) whatever schema they like, and using any key from the appropriate verification method in their DID doc to sign. And VCs issued in this ad-hoc way can be verified by simply looking for the schema a verifier hopes to see. This totally works.

But there are several useful properties that we give up when we operate in this ad-hoc fashion, that we would retain if we used credential definitions:

1. Discoverability (not of individual VCs, but of the VC-publication activities and intentions of institutions)
2. A stable target for reputation
3. A formal versioning strategy

As an approximation, credential definitions can provide, for VCs, the same sort of publication formality that a Debian repo provides for Linux artifacts, or that an app store provides on a mobile platform. Is it possible to publish artifacts without such mechanisms? Absolutely. But by publicizing and regularizing the behavior of software "issuers", they have a powerful effect on the integrity and predictability/trust of the ecosystem as a whole. (I admit in advance that this analog is imperfect. App stores are centralized. I'm not arguing for centralization as a defining characteristic of VC issuance.)

Re. discoverability: without a cred def, there is no piece of data that describes the publication activities and intentions of an institution - there are only individual pieces of evidence (VC instances) that suggest those intentions. I may see a credential for a PhD, signed by Harvard and issued to Alice. But I don't know whether Harvard plans to use that schema with its next PhD credential. Harvard is not on the record anywhere as having any intention to stick with that schema. *With* a cred def, discoverability for such matters is at least conceivable. (DIF credential manifests are imagined to be published on a company's web site, possibly under .well-known. This accomplishes a similar purpose. I believe it does so in a way that conflates some other issues, but perhaps we could merge cred defs into/with cred manifests at some point...)

Re. reputation: Tying the reputation/gravitas of a credential just to its issuer is incorrect. Harvard's credentials about academic achievements of its students are likely to have a stellar reputation; Harvard's credentials that let a member of the campus custodial staff into the laundry room of a dorm may be highly suspect. This is NOT just because the problem domain is different; instead, the types of vetting and assurance that precede issuance may differ radically, *even if the same key signs both credentials*. You could say, "Well, right; we'll tie the reputation of the VC to the issuer plus the schema." But that's not quite right, either. In the US, there's been a move by the federal government to push some states to improve the procedures they use to vet holders before they issue driver's licenses. States that comply get to announce that their driver's licenses now carry the "Real ID" endorsement, and are considered secure enough to be used to board a flight in domestic travel. So, credential reputation is affected by the Real ID change, but the schemas and the signers of the credentials don't change. I suggest that the correct association for reputation should be issuer+intention/process+schema - which happens to be the scope of credential definitions. This is approximately like the reputation we see in the app store, where Google may have a great general reputation, but not all apps by Google have the same number of stars - and not all successive versions of the same app by Google have the same reputation, either.

Just like one-off builds of a software artifact, ad-hoc VCs (e.g., Alice wants to testify to the world Bob is a skilled birdwatcher, because she's observed him on Audubon Society outings) may not need reputation. But I think most VCs that are long-lived and human-centric and intended for repeated use are worthy of a more stable and nuanced target for reputation than just the issuer or the schema.

Re. versioning: Suppose Alice, Bob, and Carol all have PhD VCs from Harvard, issued a day apart, in that order.  Alice's cred uses schema A, Bob's uses schema B, and Carol's uses schema A. What can a verifier conclude about the schema Harvard's using for PhDs? There's not an orderly progression of schema versions (it goes A --> B --> A), and there's no public record that explains the variation. Did a sysadmin deploy a patch after Alice's PhD was issued, then back it out after discovering a problem? Who knows. I think this will confuse and frustrate verifiers. Imagine if this kind of variation occurred during a rollout of COVID vaccination creds that was trying to unfreeze global travel...

Indy credential definitions are immutable, versioned, and use semver semantics. Without any Indy baggage, we could say the same thing about cred defs in the larger ecosystem. This would force issuers to behave in a rational way, and to communicate the semantic shift associated with evolutions to their issuing behavior. Of course, issuers could operate ad-hoc, without a cred def - but if they used one, we'd have much greater predictability in the use cases where it matters.

So, that's the short form of my reasoning on why cred defs still have value, for ANY credential format, even if we simplify them and move them off a ledger. How we represent cred defs (e.g., in [an evolution? of] DIF's cred manifest format, or in some new format, or whatever) isn't what I care about here. I think they need to be immutable/tamper-proof. That's all. And using them all the time feels like overkill. But I think they could provide real value to the ecosystem if we explored them instead of thinking of them as an obnoxious dependency.

What do you think? Discuss on a community call?
________________________________

The information in this email and any attachments is confidential and intended solely for the use of the individual(s) to whom it is addressed or otherwise directed. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the Company. Finally, the recipient should check this email and any attachments for the presence of viruses.. The Company accepts no liability for any damage caused by any virus transmitted by this email.
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.