Implementor Guidance: Publishing AnonCreds objects using did:webvh

[swcurran]

This will not be part of the spec, or the implementors guide, but we will want a "did:tdw AnonCreds Method", and this issue is to get some ideas down on how to do that.

For most of the objects, the publishing mechanism will be:

• Use a similar method to the DID URLs in did:indy as defined in the did:indy specification. "Similar" except for the reference to the Indy Transaction ID of the Schema in dependent objects. This means the schemas are:
  • Schema: <did>/anoncreds/v0/SCHEMA/<schema_id>/<schema_ver>.json
  • CredDef: <did>/anoncreds/v0/CREDDEF/<schema_id>/<schema_ver>/<cred_def_id>.json
  • RevRegDef: <did>/anoncreds/v0/REV_REG_DEF/<schema_id>/<schema_ver>/<cred_def_id>/<rev_reg_id>.json

We propose that each object be a W3C VC signed by the DID, with the credentialSubject being the AnonCreds object.

That is all pretty straight forward. In theory, AnonCreds objects on Indy can be updated, although in practice that is not done as being unnecessarily complex -- no one has ever (AFAIK) implemented them. For the did:tdw AnonCreds Method, an update could overwrite the JSON file with new version or perhaps we could on publishing save two files, one with the _<version>.json (or _<time>.json), and one with just .json, so that the history was available.

Not listed above is the RevRegEntry object, which is a bit more interesting. In that case, it is updated each time the Issuer revokes a batch (1 or more) of credentials in the RevReg. That complexity must be handled. As defined in the AnonCreds v1 Specification RevRegEntry contains:

• An ID
• A timestamp (UNIX Time - epoch)
• An accumulator for the used by the holder to create a Non-Revocation Proof (NRP) and by the verifier to verify the NRP
• Either the full state of the credentials (a bit per credential - revoked or not) or the delta of states since the last change.
  • For the did:tdw AnonCreds Method, we will use the "full state" method.
  • Might be worth looking at the Cheqd AnonCreds Method for how that was done, and to be consistent.
  • Presumably, a compressed bit string such as is used in StatusList2021.
  • Note that the size of an AnonCreds RevReg is known at creation time, and cannot practically be larger than about 3k -- perhaps 5k at the absolute outset, which is worst case 640 bytes of data (plus, presumably, base64 encoding for about 1Kb).

The tricky part of RevRegEntry is that we MUST support multiple versions, and the querying is recommended in AnonCreds to by publication time range. A verifier will give the holder a from and to time range (although typically the two values are the same -- for a point in time -- and typically that time is now()), and the holder must find a RevRegEntry that is in that time range.

Potential solutions:

• Replicate the "history" functionality in did:tdw for RevRegEntries.
  • Probably a bad idea because of the need for the full state of the RevRegEntries every time. Even though each compressed bit string might be pretty small, having all of them in one file would get unmanagable.
• Publish a file associated with the RevRegDef that lists all of the RevRegEntries DID URLs paths:
  • Publish each RevRegEntry as: <did>/anoncreds/v0/REV_REG_DEF/<schema_id>/<schema_ver>/<cred_def_id>/<rev_reg_id>_<epoch_timestamp>.json
    • Nice to have: Publish the current RevRegEntry as: <did>/anoncreds/v0/REV_REG_DEF/<schema_id>/<schema_ver>/<cred_def_id>/<rev_reg_id>_latest.json
  • After/in parallel with publishing a new entry publish, publish an updated list that adds the new RevRegEntry as the latest. The list could be in the RevRegDef itself, or could be in another file, e.g. <did>/anoncreds/v0/REV_REG_DEF/<schema_id>/<schema_ver>/<cred_def_id>/<rev_reg_id>_entries.json

[swcurran]

Per our discussion on 2024.06.27 -- turning this over to @andrewwhitehead to design the first cut.