Capture issues

[OR13]

no interface defined for API service to call directly out to the data store ( @David-Chadwick)
concerns about public/external status checks (do we support them or not, and for whom?)
templating/construction/etc...
direct-to-holder delivery of credential support
requirements to support ZKP

[David-Chadwick]

One other issue I would like to add please is the extremity of the grey colouring that indicates the border between the Issuer's systems and presumably external systems. i) why is the credential store external? Surely the issuer will keep an internal record of all credentials that have been issued ii) surely the access control gateway is part of the issuer's system (since as I understand it from the description "securing inbound connections" it is protecting access to the issuer's system) iii) again from the descriptions, the API itself should be part of the issuer's system iv) again from the description, the key vault should be part of the issuer's system

[mavarley]

@David-Chadwick ; the reason for the change in 'domain' (that grey area) is to allow for an Issuer HTTP API Service to be a multi-tenant cloud deployment. Therefore all the components you call out (key vault, credential store, API Gateway) remain abstracted behind the API.

However, should the HTTP Issuer API allow for these (very sensitive) components remain in the Issuer domain (and depending on the tenant these endpoints can be configured) - that is an interesting idea, and requires this spec to also define those connection interfaces, I think.

Also note that the entire set of Issuer HTTP API components may be run "internally" to an Issuer Application for maximum control - ie, this service is not required to be multi-tenant/cloud.

Want to add an issue for "cross-domain security APIs" or something like that? Happy to continue the discussion.

[dhh1128]

The idea of a multitenant cloud deployment of an issuer service feels like a "there be dragons" topic. It radically changes the analysis of trust. I don't think this API should support it. (There could very well be an API that supports it, but I'm not sure it should be this API. As soon as we cross trust boundaries, we need to understand who is trusted for which things, and how those "who" entities are authenticated, and we can no longer say simply, "each deployment will lock it down per their own preferences" -- or at least, if we do say that, we lose any ability to talk about the security of what we've built.)

A similar issue is being discussed with respect to the verifier API; see https://github.com/w3c-ccg/vc-verifier-http-api/issues/10. @dlongley

[mavarley]

Closing out this issue;

33

34

35

have been created to capture concerns bundled across other issues.

12 remains active (direct API -> Holder interface)

w3c-ccg/vc-verifier-http-api#10 is capturing the cloud API issue (and a new one can be opened here for reference if needed.

[David-Chadwick]

the reason for the change in 'domain' (that grey area) is to allow for an Issuer HTTP API Service to be a multi-tenant cloud deployment.

Can you please add the HTTP API Service to the diagram. Currently it is not there. There is only the API itself there.