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

Daniel,

Thanks for raising this topic, although it is one that is quite technical
and nuanced I think it is worthwhile having an in-depth discussion on.

(WARNING: Strong opinions ahead :))

Firstly I wanted to clarify why we pursued this design goal (removing the
need for credential definitions) with our with BBS+ Signatures. Today out
in the wild digital signatures (and to that end, more broadly cryptography)
are used for a variety of important functions, verifiable credentials are
just one application. With that
point in mind when designing systems using this type of technology you can
either be what I would classify as application led or functionality led,
our approach to BBS+ I would say is more akin to being functionally led
where as Indy and the introduction of concepts like credential definitions
is more application led, whereby the application is verifiable credentials.
This is not meant as a criticism merely instead as an observation on what I
believe to be a difference in approach. Because we opted for a functionally
driven approach we looked at BBS+ through the digital signatures lense in
general rather than it as a solution just for verifiable credentials.

*A quick summary on some of the relevant differences between CL and BBS+
(for those interested :))*

TL;DR Due the scheme differences, not having credential definitions in CL
signatures is not really possible, but with BBS+ it is.

CL signatures, which are those used by Indy, are a scheme based around RSA,
whereas BBS+ are based on Elliptic Curve cryptography and more specifically
a branch known as pairing-based cryptography. Its with this difference in
the cryptographic primitives that underpin the schemes, where the
difference in many of the
notable properties stem from (e.g performance and element sizes).

When we started our work on BBS+ we realized early on that due to the
difference in underlying primitives, the generation of the effective
"credential definition" was quite different in a performance sense to CL
signatures. For instance creating a credential definition requires you to
generate some material per-attribute you would like to sign (some call
these keys others call them generators). With CL these must be what are
referred to as safe-prime numbers and large ones too, which is a
non-constant time, computationally expensive operation sometimes taking
greater than 10 seconds per-attribute. This means the generation of these
values is really only suitable to be a one off operation. With BBS+ the
same operation is ~1ms and it can be run in parallel, so generating the
effective "credential definition" on the fly becomes feasible as a step in
the signing process.

*Why I don't believe we need credential definitions (I've put some answers
inline below)*

1. Discoverability

I don't see credential definitions as the most efficient way in which to
create a means for discoverability, why not instead create a specific
vehicle if this is required? Re-purposing what is primarily designed to be
a vehicle for communicating some public cryptographic material to instead
function as a discovery mechanism is creating a fundamental coupling
between two concepts that IMO should remain separate. For instance what
about credentials issued under signature schemes that want to make
discoverable credentials, but do not have a credential definition (e.g
EdDSA)? How would they leverage the same discovery mechanism?

2. A stable target for reputation

Given that digital signatures have existed for a considerable amount of
time and have been used in a variety of cryptographically secure assertion
formats (VCs being one), if this was a notable deficit in the ecosystem
would we not see clear evidence of this in the market? Can you point to
market situations where digital
signatures in general would have significantly benefited from the eventual
signer making an up-front cryptographic commitment to the data schema of
what they will sign in the future? Again as above, does this point imply
that all other cryptographic schemes that do not feature a credential
definition have no sound / equivalent basis for "a stable target for
reputation"?

3. A formal versioning strategy

Whilst again I understand the view here, I would ask what makes other
mechanisms we have at our disposal around vocabulary / ontology versioning
insufficient and therefore warrants the creation of a mechanism like this
at the cryptographic level? Is it not the simplest and most robust solution
w.r.t VC's to have an explicit way to describe in the version of the schema
/ vocabulary / ontology of the credential? I think I'm missing what a
credential definition does differently here that warrants the added
complexity? Again as is the case with the last two points, what about
credentials issued under schemes that do not have credential definitions
(e.g EdDSA)? Would we have an alternative way to manage versioning of the
vocab? This would appear to be a problematic divergence?

As you might have established by my responses to the points you raise, one
common overarching theme is how does the concept of credential definitions
fit into the larger world of cryptography. Furthermore, what happens with
their presence and them being relied upon to serve certain functions that
alternative schemes in the space have to handle differently?

*As a counter argument to yours, I think a solution without credential
definitions are:*

1. Simpler
2. Have a better relationship with existing cryptography

1. Simpler

Digital signatures on their own can be a complex topic, even for seasoned
developers to properly understand, this is before we layer in ideas like
selective disclosure, zero knowledge proofs and anti-correlation
techniques, credential definitions add another concept that must be
explained and well understood to prevent mis-use and or security
vulnerabilities. Solutions that can live without them, I think are simpler
and easier to understand.

2. Have a better relationship with existing cryptography

This was a strong design goal from our work on this topic, we wanted to be
able to answer, down to the interface level, how BBS+ signatures could be
supported in existing KMS's (Key Management Services / Systems).

For instance today, many KMS's expose an API along the lines of:

```
const signature = kms.sign(algorithm, data, signingKeyId);
```

With BBS+ instead of the data simply being a single opaque blob ready to be
digested and signed, you have an array of data elements, beyond this no
other
arguments change.

Having to introduce the concept of credential definitions makes this
relationship more complex and difficult, for instance:
1. How are these credential definitions generated, do they involve a KMS?
2. Where do they get stored?
3. At what point in various cryptographic operations are they retrieved,
does the KMS do this or is it something external?
4. How does a KMS validate that the credential definition supplied matches
the data being signed?

In summary, I think all the points you raise about credential definitions
can be solved with more generalized mechanisms that don't create a coupling
at the cryptographic layer.

Thanks,
[image: Mattr website] <https://mattr.global>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
[image: Mattr website] <https://mattr.global> [image: Mattr on LinkedIn]
<https://www.linkedin.com/company/mattrglobal> [image: Mattr on Twitter]
<https://twitter.com/mattrglobal> [image: Mattr on Github]
<https://github.com/mattrglobal>
This communication, including any attachments, is confidential. If you are
not the intended recipient, you should not read it - please contact me
immediately, destroy it, and do not copy or use any part of this
communication or disclose anything about it. Thank you. Please note that
this communication does not designate an information system for the
purposes of the Electronic Transactions Act 2002.


On Tue, Feb 2, 2021 at 4:46 AM Jim St.Clair <jim.stclair@lumedic.io> wrote:

> I think it’s a great idea to discuss, and also drives the development of
> appropriate governance framework to establish agreement amongst
> participants for credential definitions, IMO.
>
> Look forward to collaborating.
>
>
>
> Best regards,
>
> Jim
>
> *_______________*
>
>
>
> *Jim St.Clair *
>
> Chief Trust Officer
>
> jim.stclair@lumedic.io | 228-273-4893
>
> *Let’s meet to discuss patient identity exchange*:
> https://calendly.com/jim-stclair-1
> <https://t.sidekickopen85.com/s2t/c/5/f18dQhb0S7kF8cp8ZwW5nLK-W2zGCwVN8Jbw_8QsRtKVp0H063MqbyjW16gGF888jhsZ101?te=W3R5hFj4cm2zwW3F4Fph41QWmBW1JxwY51Ly-dfW1GHFsw3ZSyG-34k72&si=8000000005266983&pi=2d636378-66ec-418a-9173-7b34e45cd6a2>
>
>
>
> *From:* Hardman, Daniel <Daniel.Hardman@sicpa.com>
> *Sent:* Friday, January 29, 2021 6:18 PM
> *To:* W3C CCG <public-credentials@w3.org>
> *Subject:* credential definitions, credential manifests, BBS+, etc
>
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> (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 communication, including any attachments, is confidential. If you are 
not the intended recipient, you should not read it - please contact me 
immediately, destroy it, and do not copy or use any part of this 
communication or disclose anything about it. Thank you. Please note that 
this communication does not designate an information system for the 
purposes of the Electronic Transactions Act 2002.