Data Integrity Proof Cryptosuite naming about anoncreds-rs HOT 5 CLOSED

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

from anoncreds-rs.

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

from anoncreds-rs.

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

from anoncreds-rs.

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

@ianco @andrewwhitehead @tra371 @gvelez17

from anoncreds-rs.

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.

from anoncreds-rs.