w3c-ccg
Why don't we just say this API is external and start designing it as such?
It seems like the fact that we still won't admit whether it is internal or external or a combination of both is causing problems.
I believe we should be building with zero trust on any of these endpoints in mind.
What technologies can get us to an external only VC API?
Can GNAP get us there?
Can ZCAPs get us there?
Can OIDC / OAuth2 get us there?
I believe we should be building with zero trust on any of these endpoints in mind.
I agree - the fact an API becomes "internal" does not automatically mean it no longer requires authorization. Maybe the parameters change, but it is still required.
I agree - the fact an API becomes "internal" does not automatically mean it no longer requires authorization. Maybe the parameters change, but it is still required.
Yes. As I've said on a number of calls, and with which those on the calls at the time have agreed. AuthZ (and hence AuthN) must be a part of the picture, and all API calls must be treated as if they're made over the longest and least secure Internet wire (so TLS or similar should also be in play).
I agree with the question this issue is asking, however I'd like to drill down on what the assumption of external vs internal API means, to me it seems to imply a different trust relationship between the server and client? IMO whether you are operating in an internal or external setting, the client being able to appropriately prove to the API that it is authorized to perform an action doesn't really change, however what the client is able to do might. For example a client that is an internal service might be authorized to create any credential for anyone (e.g specifying any combination of claims and claim values). However a client that is in-fact a wallet acting on behalf of a particular user should only be able to create credential for that particular user.
For example a client that is an internal service might be authorized to create any credential for anyone (e.g specifying any combination of claims and claim values). However a client that is in-fact a wallet acting on behalf of a particular user should only be able to create credential for that particular user.
This is business logic, not protocol or API logic. Yes, the API should enable decisions based on such business logic, but it should not be "baked in" to the API — because while some businesses will follow the logic described above, some (I daresay, most) will not.
We discussed this topic on the call today 2022-10-11. There was general agreement that we have moved past the "internal" vs. "external" language. @jandrieu noted that focusing on "Who is calling which endpoint on which component" is a better way to look at it. @PatStLouis noted that adding internal/external would be added complexity. Endpoints need to be anchored on a component and we need to specify who is calling an endpoint.
The suggestion was to close this issue and to not use the internal/external language and focusing instead on specifying that endpoints are anchored to specific ecosystem components (Services / Coordinators) and we'll focus on who is expected to call each endpoint.
We'll cover this again on the next call.
@msporny "we need to specify who is calling an endpoint." Sorry but I do not think you can do this (well you can but it is meaningless, because anyone can call any endpoint). As the earlier respondents have said, each endpoint needs to say what its authz mechanism is. I am not sure you should go as far as to define the authz rules for an endpoint, because as @TallTed implied, implementations may define their own rules. Perhaps you can write suggestions in the implementation guidelines as who you envisage should call each endpoint.
@msporny "we need to specify who is calling an endpoint."
That quote was "lost in translation" -- I didn't say it, but it was a rough summary of what the group was thinking during the call. :)
What was meant was that we specify who might call an endpoint. That is, for the /credentials/issue endpoint, it is anchored on the "Issuer Service" component and is expected that the "Issuer Coordinator" role will call that endpoint. It is not expected that a Verifier role, for example, would call the /credentials/issue endpoint. For things like the exchanges endpoint, well, just about anyone could call that endpoint.
As for authz, it's up to the implementations to choose among a set of options that we hope to clearly define in the spec. For example, if you use OAuth2, then you MUST implement it in this way (as defined in the spec) -- that part remains slightly more controversial about the details... but at this point, it's clear that most of the implementers are implementing at least OAuth2 for authz.
"Which role might call the endpoint" is perhaps what we need (and then we can see if we need any additional roles as well).
I'd say "which role(s) are expected to call the endpoint?" (and by implication, which are not).
Anyone can call an endpoint. That's the problem with endpoints.
We have to understand who is expected to call so we can have an authorization and/or authentication mechanism to enable that while preventing others. For example, holder coordinators are not expected to call the issuer service directly (the call the issuer coordinator); issuer coordinators are.
Similarly, issuer services are not expected to call verifier services, and vice-versa, although verifier services do need to access the issuer's status service (which is why the status service is separate from the issuer service in the component diagram).
And since the issuer coordinator is the one who executes business rules about issuance (and holder coordinators already talk with issuer coordinators), I would also expect that the refresh endpoint is at the issuer coordinator (called by holder coordinators) instead of at the issuer service (which is not called directly by holder coordinators).
Defining these relationships will illuminate who needs to be authenticated and authorized when.
The group discussed this on 2022-10-18. @jandrieu noted that we have some tribal knowledge and by clarifying which role is expected to call which component will clarify. @dlongley noted that when we say "who" we're talking about a "role" that is well defined in the specification.
Next steps are to raise a PR that notes two things for each endpoint: 1) which roles are expected to call the endpoint, and 2) which components those endpoints are expected to be exposed on.
@eric-schuh is working on it.