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

Happy to continue the conversation. Yours is a super interesting problem space because of the characteristics you describe. If the oracle as issuer model works then I think ‘trust-authority as certification authority ‘ will allow you to scale and keep the chain of trust as short as possible.

 

-S

 

From: steve capell <steve.capell@gmail.com> 
Sent: Monday, February 8, 2021 11:56 PM
To: steve.e.magennis@gmail.com
Cc: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>; Hardman, Daniel <Daniel.Hardman@sicpa.com>; W3C CCG <public-credentials@w3.org>
Subject: Re: credential definitions, credential manifests, BBS+, etc

 

Hi Steve,

 

I read your paper and keen to talk about the chain of trust question.  

 

Our use case for VCs is cross border trade documents issued in the exporting country and verified in the importing country. In every single example, there is a fundamental need to establish the chain of trust in the exporting jurisdiction up to the national regulator - so that the importing jurisdiction can be confident of the claims - becuase they otherwise have pretty much no way to verify the identity or authority of the issuer directly.  

 

So - how best to do this?

* for now, we use the "oracle as issuer" model - ie the exporting regulator issues the credential on behalf of the actual issuer - which is simpler for both issuer and verifier because there's only  one credential to verify.
* but as this scales, we may need to support linked sets of credentials that establish the chain of trust.  

I have to write a strategy paper on this and keen for contributions of ideas from the community.

 

On Tue, 2 Feb 2021 at 12:16, <steve.e.magennis@gmail.com <mailto:steve.e.magennis@gmail.com> > wrote:

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.




 

-- 

Steve Capell