Enable in production the DID-Auth allowlist to check that only authorized Issuers can write to TOB

[swcurran]

Extend the DID-Auth capability to check a allowlist to make sure that only authorized Issuer/Verifiers can write to the production instance of TOB for BC and Ontario. This should extend to any write operations related to the API - including registering as an Issuer/Verifier. That might be a chicken and egg issue - you can't register with TOB until you have registered :-). Presumably, we'll add a config-controlled (at least for now) mechanism (e.g. OpenShift Secret) to allowlist a DID so that the Issuer/Verifier can use the "register Issuer agent" api call.

The allowlist mechanism should include a way to NOT allowlist limit access on non-production instances so that we can continue to develop, test and run workshops.

[swcurran]

@nrempel - any thoughts now on how we can add this to the IndyCat Agent - IndyCat CredReg interface? How would we bootstrap an agent being able to prove credentials on connecting/for API calls?

Good if you could at least add some "current thinking" notes to this and then unassign/push it back to the backlog if we aren't going to do anything about it immediately. Or just unassign/push back if there is nothing to say.

Thanks!

[nrempel]

What I propose with the new Indy Catalyst Agent is that we turn off auto-connect and have the controller (credential registry) listen to webhooks and broker the connection when an invitation is received. We could have a configurable whitelist in the credential-registry and it would only complete a connection flow if the service endpoint is in a whitelist of domains.

In this case, if a connection is established, then it is assumed that they have permission to register an issuer and modify the credential registry.

This method should be do-able right now without any changes to Indy Catalyst Agent. I'll think about this over the weekend and come back to it on Monday but let me know if you see any pitfalls with that approach.

[swcurran]

The issue with this is how to bootstrap the whitelist. If the connection is a normal pairwise, then the DID won't be known until it's known. Suggest that a UI be invoked during the flow. Something like:

• connection accepted, tagged as unverified
• register issuer call attempted - send to human queue to accept/reject.
  • anything else is rejected until an accepted response received.
• on acceptance, tag the connection as verified, allowing the issuer to do other things.

In the future, we would do this via a proof and human review of the proof. But we need the issuer to be able to get a credential prior to that - which is back to the bootstrapping problem except we don't have a credential issuer.

[jljordan42]

Issuers would use their public DID no? For example, so we can add it to the /issuer page in ToB.

[swcurran]

That's not the typical model for connections (e.g. the connection would be a pairwise one, I would think). But yes, the published DID could be used as the basis of the whitelist. I still lean to the right place to do the management of the whitelist would be through a web interface as part of the controller, and have the interface added at the time of registration. Pretty sure the issuer DID is communicated through that protocol.

[nrempel]

So I think the approach is to have the org book create the invitations and send the invitation to the issuer out-of-band. A connection must be made before anything can be written to the org book since all data comes through did comms.

If this works, we could use the swagger API to do this right now and no whitelist is required.

[swcurran]

That sounds like a good idea. I'm thinking we have an admin API (for now) and then an admin UI that allows us to create an invitation and put an issuer name, contact name and email address on it, and be able to update that later. Of course the issuer registration provides information as well.