The anoncreds-data-types module contains an identifiers directory with logic around creation, splitting and validation of the identifiers in anoncreds objects.

The AnonCreds specification has updated identifiers to allow both the legacy indy style identifiers (different per object type) and URIs.

As identifiers don't contain specific elements anymore, but just an URI we need to determine how much validation is still needed.

These are the identifiers that should be updated:

• [ ] CredentialDefinitionId
• [ ] RevocationRegistryId
• [ ] SchemaId

This task only focusses on adding validation support for the URI type, but doesn't remove logic related to handling the legacy identifier type, this will be handled in separate tasks.

For each of the identifiers the following should happen:

• [ ] Update the Validatable implementation for the identifier type to accept both the legacy indy style (currently implemented) and the new URI style according to the AnonCreds specification.
• [ ] Remove the Qualifiable implementation for the identifier as it isn't needed for the anoncreds implementation
• [ ] Add utility methods to determine if the identifier is of type legacy indy identifier or URI. Can be either through something like an identifier type (uri, legacy_indy), or just adding two methods is_legacy_indy_identifier() and is_uri_identifier() (thinks the second is simplest).
• [ ] Rename .parts() to .legacy_indy_identifier_parts(). This should throw an error if the type of the identifier is not a legacy indy identifier

This is the first PR introducing RevocationList model outlined in https://github.com/hyperledger/anoncreds-spec/issues/108 and #24.

• introduce RevocationList struct with serde to match outlined json, with tests
• update create_or_update_revocation_state function for prover and FFI. This now takes in either 1 RevocationList to create or optionally an old one, does a comparison and update the revocation state.
• initial end to end test in anoncreds_demo

Additional documentation is added to highlight the unchecked interval, which I am looking into for #36 and #41

closes #4 closes #13 closes #23

It also picks up some tasks from other tickets. Mainly with regards to the "remove to_unqualified...".

Might have to do some clean up (most String can be converted to &str).

There are two major TODOs which I need some help with.

Right now we have some presentation filter, like: schema issuer, schema name, etc. Before we could derive this from the schema id, but not anymore. How will we deal with this? As the schema id has no guarantee of being "qualified" we can not use it.

I believe we can do these from the filters without changing anything:

    Ok(Filter {
        schema_id,         // YES
        schema_name,       // NO
        schema_issuer_did, // NO
        schema_version,    // NO
        cred_def_id,       // YES
        issuer_did,        // NO
    })

We can allow for more data to be passed in which can be gotten from an object resolution on the ledger or whatever.

The second one is the wrappers. I did not update them, but updating them would be trivial as they are just FFI-wrappers without complex logic build atop. I can create an issue for that if there is none.

We need to rename the indy-credx module to the anoncreds module

• [ ] Rename indy-credx directory to anoncreds
• [ ] Update Cargo.toml and remove indy terms, add anoncreds naming/terms
• [ ] Rename impl_indy_object to impl_anoncreds_object
• [ ] Rename impl_indy_object_from_json to impl_anoncreds_object_from_json
• [ ] Rename IndyObject to AnonCredsObject
• [ ] Rename AnyIndyObject to AnyAnonCredsObject
• [ ] Rename IndyObjectId to AnonCredsObjectId
• [ ] Rename IndyObjectList to AnonCredsObjectList

Depends on #43

closes #45 closes #46

• I had to patch openssl-src-rs, nothing functional, https://github.com/alexcrichton/openssl-src-rs/compare/release/111...blu3beri:openssl-src-rs:release/111 as it did not provide a build script for the target aarch64-apple-ios-sim. Since they do not accept non-security fixes for this branch we can not get this upstream, unless we depend upon openssl 3.

Work funded by the Government of Ontario.

Signed-off-by: blu3beri [email protected]

As the identifiers can now be any URI, we should update the methods in the AnonCreds library to not generate the id values, but rather allow the user to generate the IDs themselves based on the AnonCreds method they're using.

• [ ] Update the credx_create_schema ffi method based on the chosen approach
  • remove origin_did as parameter
  • remove the seq_no parameter from the schema creation (but keep it in the data model for now to not break cred def flow)
  • based on the chosen approach, add an schema_id parameter or not
• [ ] Update the create_schema issuer.rs method based on the choses approach
  • remove origin_did parameter
  • remove the seq_no parameter from the schema creation (but keep it in the data model for now to not break cred def flow)
  • based on the chosen approach, add a schema_id parameter or not
  • remove the generation of the schema_id based on the schema values
• [ ] If the frist approach is taken, we need to update all validation logic and make the schema_id optional (but only in some cases). This requires some refactoring probably

One things to figure out is how we want to approach the generation of the ID, and whether it already needs to be present when we call the methods that create the objects. There's two approaches we can take:

Approach 1

Call the creation method (e.g. create_schema) without any identifier and then return the created object (the schema) without the id property. The schema is now created and the id property can be added later when the object is written to the ledger.

The advantage of this appraoch is that it allows the id generation process to be based on the contents of the object (schema), or it allows the id to be known after the object has been written to the ledger (if e.g. the ledger generates some identifier).

Approach 2

Call the creation method (e.g. create_schema) with the identifier and return the created object (the schema) with the id property.

The advantage of this appraoch is that is allows the anoncreds library to validate the identifier to be a valid URI / legacy indy identifier and we don't have a in-between representation of the model (all fields except the id).

Moved indy-data-types inside of anoncreds crate. In this process I removed "serde", "cl" and "cl_native" features (because they are mandatory for the anoncreds code). Other features are moved.

We need to rename the indy-data-types module to the anoncreds-data-types module

• [ ] Rename indy-data-types directory to anoncreds-data-types
• [ ] Update Cargo.toml and remove indy terms, add anoncreds naming/terms

The indy-shared-rs repository contains an implementation of the wallet query language (WQL). It seems the wql module is used currently used by Aries Askar and Indy CredX. The new AnonCreds library will also need to support .

As Aries Askar now depends on indy_wql, it may make sense to make both AnonCreds and Aries Askar depend on WQL. Need to gather some feedback on this approach.

• [ ] Determine where the wql code will live (indy-shared-rs, anoncreds, aries-askar)
• [ ] Determine whether the WQL needs to be standardized as part of AnonCreds
  • It could also be a separate specification, with separate implementation

If we keep it in here, we should rename it to anoncreds-wql (or maybe even just wallet_query_language)

Discussed:

• Move implementation to Aries Askar (ask Andrew Whitehead)
• Interface in anoncreds(-utils) that is only used for validation in proof request (can be really simple)

This PR updates the MAINTAINERS.md file to follow the outline from the Besu repo.

I added the current AnonCreds maintainers as active maintainers (@WadeBarnes, @andrewwhitehead, @swcurran, @TimoGlastra).

In addition I added two new maintainers that will start working on the implementation and reviews:

• Darko Kulic (@dkulic) from SICPA will start with the changes to the AnonCreds library (as described in the board): https://github.com/orgs/hyperledger/projects/16. Adding him a maintainers makes sure he can manage issues, add new items to the project board and merge pull request.
• Berend Sliedrecht (@blu3beri) from Animo will not start contributing right away but will be mostly involved in PR reviews and merging PRs for now. Adding him as a maintainer makes sure he can review and merge PRs, and manage issues in the repos.

To finalize this:

• @blu3beri, @dkulic if you want to be added as a maintainer please reply in this PR that you are willing to become a maintainer of this project
• @WadeBarnes, @andrewwhitehead, @swcurran, @TimoGlastra if you agree with the changes from this PR please approve this PR. If you don't agree please let us know why and how to change it. Once we have three approvals (one of which is mine, so two to go) and no vetos we can go ahead and merge and add the new maintainers.
• @dkulic, @andrewwhitehead, @swcurran, @WadeBarnes could you share your LFID so it can be added to the maintainers file

@andrewwhitehead I am not sure why it was a dependency, but if we have to keep it for some reason we can of course keep it in.

Signed-off-by: blu3beri [email protected]

The proposed RevocationStatusList field name that contains the current accumulator value is currentAccumulator.

As the accumulator is in the RevocationRegisty struct in libursa, the accum field is private and serde with the same field name.

Current situation is to keep the field name accum but we will need to either update the specs or find a workaround for serde.

Partially closes #34

• Adds IssuerId property to the Schema and CredentialDefinition.

This is reflects the PR for adding the issuerId to anoncreds objects.

(revocation needs to be done but is omitted here for conflicts with #37.

Signed-off-by: blu3beri [email protected]

This is an issue with existing anoncreds implementations (indy-sdk and credx) and is illustrated in an aca-py integration test:

https://github.com/hyperledger/aries-cloudagent-python/blob/main/demo/features/0454-present-proof.feature#L120

When a proof includes both revocable and non-revocable credentials, and the request includes the revocation timestamp at the REQUEST level, then the proof will fail (even though it should pass).

Note that when the revocation interval is requested at the ATTRIBUTE level, the proof will pass (see integration test https://github.com/hyperledger/aries-cloudagent-python/blob/main/demo/features/0454-present-proof.feature#L100)

The NonRevocationInterval in the PresentationRequest on the request or the attribute/predicate level are not compared with the timestamp of which the prover has updated the RevocationState to in creating the Presentation.

Given the verifier only provides RevocationRegistry (aka Accumulator value) for the timestamps in the NonRevocationInterval, the required RevocationRegistry for the timestamp given in the Presentation will be missing and would not cause a revoked credential during that interval to be verified. However, if the verifier provides RevocationRegistry mapped to timestamps outside of the interval, a revoked credential can be verified.

This might also be related to the issued in #36, i.e. if the RevocationState is for a timestamp that is outside of the one defined in the PresentationRequest, then regardless if it has been revoked, the verifier might not supply the Accumulator value for such a timestamp.

closes #33

Draft PR for removing / integrating the indy-utils within the anoncreds package

• NOTE: indy-vdr relies on the indy-utils package so there will some minor duplicate code. (e.g. base64/58)

Work funded by the Government of Ontario.

Signed-off-by: blu3beri [email protected]