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

>>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?

As one of the people who helped invent Cred Defs, I can tell you that your summary “primarily designed to be a vehicle for communicating some public cryptographic material” is inaccurate. They had two design goals, and one obnoxious design requirement. The goals were:

1. Facilitate reputation/discoverability
2. Provide an indirection between DID docs and high-stakes credential issuance

The obnoxious requirement was that we had to put public keys in them.

(Design goal #2 is worth an aside, because it enters into the rest of this discussion a bit. In most large orgs with sophisticated IT, root certs are managed by different people and different processes than, say, the cert for one department’s web server. We believed the same thing would be true of DIDs – that amazon.com’s root public DID would need to create an indirection to the keys its HR department uses to issue employee VCs. Rotating the keys for one should not require rotation for the other. That’s a whole ‘nuther conversation…)

So, the cryptographic property was secondary. And I am suggesting that, now that the cryptographic function of cred defs is unnecessary (a positive change that I welcome), we can return them to their primary function. This does purify the architecture in a desirable way, as you suggest.

Regarding “why not create a separate vehicle”: Yes. That’s what cred defs are. The separate vehicle. Separate from a VC. Separate from a schema. A way to announce (and by extension, discover) an org’s ongoing intentions with respect to issuance.

>>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?

The crucial phrase that is separating our perspectives here is “cryptographic commitment.” You are seeing cred defs as being inherently cryptographic. I care little about their cryptographic nature and am not asserting their value on that basis, now that BBS+ has rendered that annoying requirement obsolete. Essentially, cred defs have reverted in my mind from a fancy and heavy instrument with lots of crypto to their originally intended form, which is like any signed document that constitutes an indirection declaring an org’s intentions. Signed docs that declare an org’s intentions are very much the basis of reputation in the world today. Examples include:

* Having an announced policy that legal agreements entered into by an org must follow standard templates (e.g., “our standard NDA”), or externally published recipes (“a standard Apache 2 license”), as opposed to having every signed legal agreement require one-off analysis and decision-making.

* The /.well-known mechanism that you helped develop, that declares an org’s intentions to use decentralized identity constructs with an internet domain

* Published privacy policies and terms of service

* Public commitments to governance or regulatory constraints (seeing a notice about cookies on a website as a way to comply with GDPR; notices that say “we are an equal-opportunity employer”; signing the Agile Manifesto or the EFF’s core principles; formally espousing corporate responsibility initiatives)

* Any legal contract that is public as opposed to private.

>>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"?

This has nothing to do with cryptographic schemes. Use whatever scheme you want. What I am claiming is that a VC is about an institution’s claims with respect to a subject, whereas a cred def is about an org’s intentions with respect to its own issuing behavior. Knowing the latter is independently useful, cannot be inferred reliably from individual VCs, and strengthens the inputs to reputation.

>>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?

Versioning a schema/vocabulary/ontology is also important and useful. I’m a big supporter. But it solves a different problem. It tells how data is structured or what it means, not how the data in question fits into the larger picture of the issuer’s publicly announced intentions or patterns of behavior. The latter question doesn’t change whether the data is verifiable, but it *does* influence reputation. As I tried to show with my example of Harvard PhD VCs versus employee laundry VCs, schema and issuer do not fully explain the reputation we want to ascribe to a VC.

>> 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?

This question again surfaces our disconnect. I’m suggesting that schemes and credential definitions are not closely related, once you jettison the incorrect narrative that cred defs are about cryptography. Rather, any scheme can use cred defs – and should think about doing so, for cases where issuing behavior is intended to be stable and public and high-stakes.

>>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.

I agree that ignoring cred defs is simpler. I don’t agree that ignoring them is more secure. The very fact that a credential is an anomaly with respect to an issuer’s intentions is a vital clue about abuse. Yes, I have a credential using schema X version 1.7, correctly signed by Harvard. But Harvard announced two years ago that they are only going to issue using schema X version 2.0, and the issuance date is today. What gives? Yes, this credential looks to be in order – but Harvard’s never used this particular revocation strategy before, and have no published intention to do so. What gives?

Cred defs add constraints to the system. More processes/people have to be hacked to co-opt an ecosystem where they are in active use. You are correct that those constraints are a tradeoff – which is why I suggested that they are not always worth the effort.

>>Have a better relationship with existing cryptography

This is a red herring. I’m suggesting that you can keep your function prototypes and all the simplifications that you accomplished with your BBS+ work. They’re great. And I’m suggesting that a VC could simply have a field that declares its cred def, if that’s desired. If the field is present, it doesn’t have to be resolved to a ledger, and it doesn’t have to change the args to any functions. It’s simply an indirection that documents the intentions of the issuer a bit better, enhancing what verification is possible and allowing independent update of DID doc and those intentions.
________________________________

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.