Proposal and rationale for eliminating the AnonCreds @context array entry from at least VC, possibly VP

[swcurran]

We've been digging into this issue for the last couple of weeks. I've created this document[1] that has lots of details/rationale about the approach, with only a few questions. I have one fundamental question to ask, and provide a <tl;dr> below of the document.

[1] https://hackmd.io/@BYJVN-mpSCe5H3eaIw7-7g/ryk4dvIIp

Fundamental question: To use the proof.type of "DataIntegrityProof" with a named cryptosuite, I believe we have to use W3C VC v2.0 -- is that correct?

<tl;dr> of the document content about what we should do:

It is a good idea to at least eliminate the VC AnonCreds @context array. To do so:

• Define the VC proof as a Data Integrity Proof with the cryptosuite of AnonCreds2023.
      - Question: Does that require converting to the W3C VC 2.0 Data Model?
      - If so, the IssueanceDate needs to be changed to validFrom
• Remove the AnonCreds @context from a VC issued with an AnonCreds proof.
• Eliminate the CredentialSchema and CredentialStatus items from the VC.
• Move the needed data from those two sections into the proofvalue of the AnonCreds2023 Data Integrity Proof -- at the cost of developer usefulness.

It is not strictly required for also eliminating the AnonCreds @context array entry in the VP -- details in the doc on the rationale. However, if we do want to eliminate it:

• Apply all the same changes to all of the derived VCs in the VP.
• Define the VC proofs in the VP as a Data Integrity Proof with the cryptosuite of AnonCredsCredentialPresentationProof2023.
• Define the VP proof as a Data Integrity Proof with the cryptosuite of AnonCredsPresentation2023.
• Replace the current structure in the credentialSubject item for a predicate with a string. Ugly, but possible.

[swcurran]

Thanks all for the AnonCreds meeting today (agenda, recording) meeting today (presentation, HackMD Document). The following is the summary of the changes that are to be made:

• Internal flag to simplify switching from generating VCDM 1.1 and 2.0 VCs. For now, set it to 1.1.
  • Differences: 1.1 needs the DataIntegrityProof @context and "@vocab" (not needed in 2.0) and in 2.0 "issuanceDate" becomes "validFrom".
  • Flag is not dynamic (unless there is an easy way to do this...)
• Use the proof type of "DataIntegrityProof" and the three cryptosuite definitions (see previous email).
  • anoncredsvc-2023, anoncredspresvc-2023, anoncredspresvp-2023 (open to suggestions on the values to use on this...)
• Move the AnonCreds specific items (notably, the IDs for the Schema, CredDef, RevRegId) into "proof"
  • Do not add the "CredentialStatus" item.
• Leave the "predicates" displaying as is -- covered by the "vocab".

Over to you, @Artemkaaas and team to complete.

Thanks!

[Artemkaaas]

@swcurran I open PR in anoncreds-rs repository to follow the new design: anoncreds/anoncreds-rs#291

[swcurran]

Thanks! @andrewwhitehead @TimoGlastra @gvelez17 FYI.

[Artemkaaas]

@swcurran According to the vc-data-integrity spec proofPurpose and verificationMethod are required properties, but they are omitted in your design.

[TimoGlastra]

@Artemkaaas The vc-data-integrity specification is leading. But it's a bit weird, as the verificationMethod needs to point to a verificationMethod object, but with AnonCreds you don't really have a verificationMethod, you have a cred def id. Can we use the credentialDefinitionId as the verification method? It's an URI, and it would add some context to the credential around which credentialDefinitionId is used

[swcurran]

For proofPurpose we can (for now) use assertionMethod. OK as that is generally what Proofs are used for, but limiting if not controlled by the end user. Let’s do that for the short term and add an open issue for putting it in.

I really like @TimoGlastra ’s suggestion about putting in the cred_def_id, as it aligns with the purpose of the Verification Method — a reference to the public key (and in the case of a Cred Def — a bit more). That definitely works for me.

[Artemkaaas]

cred_def_id suites for anoncredsvc-2023 and anoncredspresvc-2023 proofs but not for anoncredspresvp-2023 as it may contain multiple credentials.

[swcurran]

That’s a tough one. There is nothing obvious to use. The proof is there to prove holder binding via the link secret across all verifiable credentials. The holder is proving that they know the link secret that is blinded in each of the source VCs. I think we should (arbitrarily) pick one of the CredDefIds and use it. We are using that URL — and others, admittedly — so it’s not wrong, just incomplete. @Artemkaaas — to get something in place, I suggest we go with that. I can puruse the issue with Manu, et al. in the Data Integrity community to see if there is other guidance.

[swcurran]

In looking at the latest question, I looked a little more at proofPurpose. Per this, section 7.2, item 3.1.2 in the VCDM, the value should be assertionMethod for a VC and authentication for a VP.

So @Artemkaaas, please adjust the VP hard-coded values to those.

[gmulhearn]

Hey @swcurran what's the status on this issue?

I noticed the PR is merged: anoncreds/anoncreds-rs#291, also noticed that RFC0809 implies that the anoncreds w3c data model has switched to use DataIntegrityProofs: https://github.com/hyperledger/aries-rfcs/blob/main/features/0809-w3c-data-integrity-credential-attachment/README.md#binding-in-credential

Does the anoncreds spec example need to be updated in relation to this? it still uses the new @context/type: https://hyperledger.github.io/anoncreds-spec/#w3c-verifiable-credentials-representation

cheers!