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

Daniel, et. Al.

 

I've been pushing on the idea that external trust ecosystems should be
responsible in most cases for establishing the criteria and standards by
which holders and verifiers should evaluate the claims of an issuer. When
needed, and certainly it is not always needed, the VC mechanism can surface
signed 'bona fides' to a verifier as well as a trust chain that can extend
as far as necessary to instill the required level of confidence in the
claims. If we look at VCs as a medium to conduct messages (claims) I think
it makes most sense to let others do the messy work of 'ensuring' the issuer
has the right authority, certification, context, processes, best practices,
certifications, recent audits, etc. to make the claims they do and that
verifiers have the ability to quickly evaluate the relevance of the claims
they receive based on who they already trust.

 

Here is a draft paper
<https://drive.google.com/file/d/1wDrvgAUG7nkv4tW-Dz2ZniaBUvNA6jX5/view?usp=
sharing>  I wrote on this topic, I suspect some of it will feel very
familiar. 

Thoughts and comments appreciated. 

 

 

 

From: Hardman, Daniel <Daniel.Hardman@sicpa.com
<mailto:Daniel.Hardman@sicpa.com> > 
Sent: January 29, 2021 5:18 PM
To: W3C CCG <public-credentials@w3.org <mailto: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.