Tenant UI Anoncreds endpoints

[loneil]

Right now the Tenant UI uses the existing indy credential details to set up schemas and creds, and issuance 2.0 endpoints (again with Indy) to fetch and action issuance protocols.

If using an askar-anoncreds tenant this stuff won't work for doing anoncreds work.

To support that in the Tenant UI the following (at least, need to verify if more) changes would be needed.

• Detect wallet type for the tenant so it can be used to conditional display (on login likely, might already be in there)
• When creating schemas, if an anoncreds tenant is used, call the anoncreds endpoint instead
• Same for cred defs
• The above 2 items are going to be (in the UI at least) affected by the Traction schema/cred storage changes (insert ticket here) needed
• When issuing, if an anoncreds tenant the filter part of the offer body will need to be anoncreds instead of indy
• Revocation calls need to use anoncreds endpoints
• Same for presentation requests
• Any Holder changes??? Maybe leave for a separate ticket if it's not just the same credentials and cred exchange endpoints
• TBD more?

[loneil]

Note this stuff will affect the Sandbox anoncreds workshop (which uses Indy creds for definitions/issuance/proof/revocation). If we cut sandbox to anoncreds these would be necessary changes for the instructions. cc @swcurran

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[swcurran]

I think this work should be done sooner than later. We definitely don't want any new Traction tenants using anything other than AIP 2.0 and askar-anoncreds wallet type.

[swcurran]

If there is a way with the API (vs. the UI) to accomplish what is happening in the UI, but with AIP v2.0 and askar-anoncreds, let's do that. @PatStLouis -- once I get your notes for creating an AnonCreds Tutorial on Traction Sandbox, I'll look at updating the ACA-Py AnonCreds Workshop to do the same, and bypass the Traction UI until this is done.

[esune]

The TenantUI is just orchestrating API calls, so it should be possible to model everything as API requests.

I wonder whether we actually want to update the TenantUI vs putting effort into a separate "intermediary" service to abstract away from the ACA-Py APIs, or both. I see the usefulness of adding functionality to the TenantUI for workshops and general adoption, but for BCGov specific adopters it might be more valuable to create a common, managed "entry point".

@cvarjao do you have input/preferences?

[loneil]

I think this work should be done sooner than later. We definitely don't want any new Traction tenants using anything other than AIP 2.0 and askar-anoncreds wallet type.

Everything in the Tenant UI uses the AIP 2.0 endpoints. The Sandbox could switch over to create anoncreds tenants whenever, and the tenant UI could trivially be changed to support the /anoncreds endpoint versions instead of other ones where needed. It's just that anoncreds workshop that references using the existing endpoints the Tenant UI calls that are not /anoncreds.

[swcurran]

@loneil -- I'm confused by your statement about needing to change the instructions in the Tutorial -- which makes me think I don't understand what is being proposed.

The Tutorial does not reference the API endpoints -- it directs the user to use the Traction UI for all of the work. So if we are "under the covers" changing the UI to use AIP v2.0, I don't see the Tutorial has to change. If it does have to change, that's fine and we can do that -- I'm just not sure it needs to based on your comment.

I realize changing the UI doesn't change what API a developer building an issuer chooses to use. I just think it is technical debt in Traction that we should eliminate -- but perhaps not a priority. I do agree that defining a higher level API that abstracts the protocol and credential format would be helpful.

[loneil]

@swcurran It's not an AIP issue specifically (the connections, issuance, proof, etc UI parts already call 2.0 versions) it's that the instructions reference creating schemas and cred defs etc through the Tenant UI. Those call the existing API endpoints for doing that. If the Sandbox environment were to create askar-anoncreds tenants by default, then the Tenant UI would not work for those tenants (or at least, not use the appropriate askar-anoncreds calls, I think that's a breaking change).

So for example when instructed to go and create a credential definition through the UI button it would call POST /credential-definition But if a tenant were being created as askar-anoncreds, we'd want the UI to be calling POST /anoncreds/credential-definition with any equivalent changes to request/response body, etc. Unless I'm mistaken.

But yes, if we change the tenant UI to account for that the instructions probably can remain. We'd just need to make those tweaks first before making askar-anoncreds tenants in the sandbox env.

Same thing for issuing the credential through the UI, the body of /issue-credential-2.0/send-offer fills in indy instead of anoncreds right now.