search

hyperledger / anoncreds-rs

anoncreds-rs
https://wiki.hyperledger.org/display/anoncreds
Apache License 2.0
74 stars 55 forks source link

Data Integrity Proof Cryptosuite naming #315

Closed auer-martin closed 9 months ago

auer-martin commented 9 months ago

I know this has been discussed before, but I would like to reiterate the current use of Cryptosuite properties when working with w3c credentials and presentations.

Currently, we use anoncreds-vc for credentials, anoncredspres-vc for derived credentials, and anoncredspresvp-2023 for presentations.

There are a few issues with this approach.

  1. Having multiple different identifiers here naturally introduces some complexity. E.g., checks and mappings for these identifiers.
  2. It is not really in line with what the Data Integrity spec defines as a crypto suite, an identifier for a set of specific cryptographic primitives, as we don't change the cryptographic primitives.
  3. Also, other crypto suites supporting selective disclosure don't follow this approach, e.g., https://www.w3.org/TR/vc-di-bbs/.

During a working group call, it was suggested to use only a single crypto suite value, e.g. by encoding the required metadata in the proofValue. I think it would make sense to move in this direction.

TimoGlastra commented 9 months ago

I think Many suggested that it can all be one identifier

I'm a proponent of this, as it also simplifies the querying and PEX logic a lot.

cc @Artemkaaas @swcurran

swcurran commented 9 months ago

Makes sense. I had been thinking about the need to know the crypto suite in combination only with the proofValue field. But I gather that you are saying the context of where the cyrptosuite is referenced would also be considered and is sufficient for use in interpreting the proofValue.

In the meetings, we didn’t get to this issue to discuss it and so it never changed.

FYI — looking at the code, it appears the strings used are anoncredsvc-2023, vc-anoncredspres2023, and anoncredspresvp-2023

swcurran commented 9 months ago

@Artemkaaas — would you be able to make this change?

@ianco @andrewwhitehead @tra371 @gvelez17

TimoGlastra commented 9 months ago

But I gather that you are saying the context of where the cyrptosuite is referenced would also be considered and is sufficient for use in interpreting the proofValue.

Mostly yes, but the actual type (vc, presvc, or presvp) could also be encoded within the proofValue. The cryptosuite should identify so you know how to parse the proofValue, within the proofValue you can include any metadata you want to know how to further process it.

From an email that Manu sent:

One trick we used in the ecdsa and BBS cryptosuites was to use a header on the proofValue that differentiated between the original proof and a derived proof. This way, we could use the same cryptosuite identifier: "anoncreds-2023" and the first byte of the proofValue told you whether or not the proof was the original proof or a derived proof.

swcurran commented 9 months ago

Got it. So sniff the proofValue and process it according to that encoding.