# A specification for ledger-agnostic AnonCreds

## Abstract

AnonCreds are a novel means of providing digitally verifiable data that is privacy-preserving and tamper-proof (for SSI). Currently, AnonCreds are coupled to Hyperledger Indy, however the underlying cryptographic logic is based on the Hyperledger Ursa library and henceforth uncoupled to any specific ledger. Many real-world use-cases for SSI implementations come with using multiple and different types of ledgers for the same user domain. For instance, a country could use verifiable credentials based on ledger A for issuing a driving license and certificate of citizenship, whilst using ledger B for banking-related matters. The ability to anchor AnonCreds related objects (schemas, credential definitions, etc..) on theoretically any ledger, is the goal of this proposal. The outcome is an AnonCreds specification describing how to use AnonCreds in a ledger agnostic way, based on the current Hyperledger Indy implementation, with modifications/shortcomings that describe possible extensions and updates to the current speicfication (such as removing the binding to CL signatures, or the revocation scheme).

- Proposed solution
- use-cases
- requirement

## Work delivered during RWOT

During RWOT extensions were made to the AnonCreds specification. Specific focus was on making the current non-standardized AnonCreds specification ledger agnostic. Pull requests were made for the simpler objects (such as the schema, credential definition, and revocation registry). The revocation state data models, and the W3C Data Model were discussed and will be added to the final paper.

* Changes to Schema definition in the spec [PR](https://github.com/AnonCreds-WG/anoncreds-spec/pull/78)
* Consistent human-readable spelling
* Ledger Agnostic AnonCreds conformant data model
* Changes to Credential Definition data model in the spec [PR](https://github.com/AnonCreds-WG/anoncreds-spec/pull/80)
* Consistent human-readable spelling
* Ledger Agnostic AnonCreds conformant data model
* Changes to revocation registry definition [PR](https://github.com/AnonCreds-WG/anoncreds-spec/pull/82)
* Consistent human-readable spelling
* Ledger Agnostic AnonCreds conformant data model
* Remove indy specific things and increase concision [PR](https://github.com/AnonCreds-WG/anoncreds-spec/pull/76)
* Update tails file info [PR](https://github.com/AnonCreds-WG/anoncreds-spec/pull/79)
* Added how libursa currently manages the blinding of all hidden attributes (including link secret) [PR](https://github.com/AnonCreds-WG/anoncreds-spec/pull/81)

## Outstanding work

### Revocation Data Models

The revocation data models for AnonCreds are currently very specific to how the indy ledger works. During RWOT there have been discussions on the possiblities to store and query the revocation state. An idea was discussed to create a bit index revocation state data model that the AnonCreds object method should create. Under the hood this could be generated in various ways. The exact data model still needs to be worked out.

### New Revocation Scheme

A review of a [new revocation scheme](https://docs.google.com/presentation/d/10dGC-qKU7XT2WRd_wTxK82u0FmvjJrfdXwFEiWGauE4/edit#slide=id.p) designed by Andrew Whitehead needs to happen, with an approach to integrate this with both AnonCreds and other credential types.

### W3C Data Model Representation for AnonCreds

A W3C Data Model representation for AnonCreds was discussed and reviewed. An initial version based on the learnings needs to be worked out and submitted as an `AnonCreds2022` proof type. The representation can build on the work done in this [PR](https://github.com/hyperledger/indy-sdk/pull/2223)

### Documentation on the Applied Cryptography

The final specification should provide a concise picture to guide implmentors on the cryptographic primitives and constructs that AnonCreds support.

However, much of the cryptographic material is included in the AnonCreds data model,
therefore it is important to provide description and explanation on the underlying [CL signature scheme].
In addition, it will be helpful to document what the currently implementation does,
which will also provide the basis for evolution for next specification versions.

Remaining tasks include:

* Fill out terminologies describing cryptographic material
* Add description of underlying cryptographic schemes implemented in the [Ursa library]
* Create a new section to explain the elements in the cryptographic material and how they are used

[CL Signature scheme]: https://cs.brown.edu/people/alysyans/papers/cl04.pdf
[Ursa library]: https://github.com/hyperledger/ursa

## Notes

1. (Started in docs, out-of-scope in repo - changes to [this repo](https://github.com/hyperledger/indy-shared-rs) has to be done by eg S Curran)Removing all the indy specific references within the library

a. Did validation should be a lot less strict and just check the format defined in the DID-core spec

All identifiers MUST be an URI or a legacy indy identifier

- Which identifiers are dids and which can be any? (Cheqd can use UUIDs to reference other items on the ledger I think)

b. ~~~Update terms such as `CLAIM_DEF` to `CRED_DEF`~~~ :heavy_check_mark:

2. `indy_data_types` must be transformed to `anoncreds_data_types`, but most of the types stay the same

3. (Out of scope) Genesis transactions are indy specific and must be reworked into a generic method to connect to a ledger

genesis transactions not needed for anoncreds library, this is a vdr feature

a. Maybe a user would have to implement a trait and we would have one for an indy ledger.

4. seqNo (ref) must be reworked, not 100% sure what we have to do here
ref is now becoming the full schema_id value now

a. Should be discussed with Andrew or Stephen, but it will likely be renamed to something like `SchemaId` in the `CRED_DEF` or `LinkedIdentifier` (meaning something more generic)

5. `master_secret` → `link_secret`

6. (Out of scope) Remove schema version validation, if there is any

## Questions

1. What about backwards compatibility
2. What signatures types need to be accounted for
3. Do AnonCreds Object Idebntifiers have to be qualified dids
4. What is the `origin_did`? Just the public did? [see also](https://github.com/hyperledger/indy-shared-rs/blob/d22373265f7c4cf93d59dd3c111251ef96d6a63d/indy-credx/src/services/issuer.rs#L75)
5. Revocation is out-of-scope/Shouldbe excluded?

## What needs to be done

- [ ] Determine all differences between the spec and the current implementation
- [ ] Change the current code base to reflect the spec instead of the current implementation (possibly out of scope)
- [ ] That entails:
a. Rename repository to be something along the lines of "AnonCred(s)" (needs to be done by eg S Curran)
b. Potentially move the repository elsewhere
c. Re-work/write wrappers where needed
d. Tets integration with indy and others ledgers
- [ ] Extend the glossary (eg. define `origin_did`)
- [ ] Define the data model for the different AnonCreds objects
- [x] Schema
- [x] Credential Definition
- [ ] Revocation Registry Definition
- [ ] Revocation Registry Entry
- HackMD with models: https://hackmd.io/@timoglastra/Hy5M0xXMi
- [ ] Credential Offer
- [ ] Credential Request
- [ ] Credential
- [ ] Proof Request
- [ ] Proof Presentation
- [ ] Create "Chagnes from v0.1" section for the v1.0 spec.

## Related GH work

(Draft) [PR](https://github.com/AnonCreds-WG/anoncreds-spec/pull/76) for updating the spec (WIP)
ISSUE: https://github.com/AnonCreds-WG/anoncreds-spec/issues/77 renaming terminolgy to be implementation-agnostic

## References

1. [AnonCreds Spec GH repo](https://github.com/AnonCreds-WG/anoncreds-spec)
2. [AnonCreds docs hosted](https://anoncreds-wg.github.io/anoncreds-spec/)
3. ...