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> 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>
> *Sent:* January 29, 2021 5:18 PM
> *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.
>


-- 
Steve Capell