Re: [AGENDA] VC HTTP API Work Item - July 13th 2021

I hope to attend the call tomorrow, but for now here are my thoughts on the proposals here:

> 
> PROPOSAL: How a VC HTTP API client gets an authorization token is out of scope.
> 

+1. The details of getting a token (ie, make this call using this protocol) are separate from the API being protected.

> PROPOSAL: How a VC HTTP API server validates an authorization token is out of
> scope.

+1, for the same reasons as above.

> 
> PROPOSAL: One of the authorization mechanisms for the VC-HTTP-API MUST be
> OAuth 2 Bearer tokens.

+1, this is a reasonable baseline for the API to define, even with most of the rest of the details out of scope.

> 
> PROPOSAL: One of the authorization mechanisms for the VC-HTTP-API SHOULD be
> GNAP key-bound access tokens.

+1, while I would prefer this to be a MUST, this is acceptable.

> 
> PROPOSAL: One of the authorization protocols for the VC-HTTP-API MUST be OAuth
> 2 Client Credentials. NOTE: This one conflicts with the first proposal (on
> purpose).

-1, and a big one. This brings in way too much detail to the API. It shouldn’t care about grant types, client types, or anything that happens in the process of getting the token at this level of detail. Saying this locks the API into one very specific and very narrow delegation and deployment pattern, and for no good reason. 

> 
> PROPOSAL: The VC HTTP API MUST define access actions in terms of OAuth 2 RAR
> structures.

+1. This is the core of the proposal I am making to the group. This would allow the API to define the separable actions that the API is capable of allowing, and the dimensions along which those are defined.

In other words, it lets you have a layer of interoperability that meshes with the API’s definition WITHOUT getting into details of “how you get a token” or “how you validate a token” or even “what goes inside a token”. 


Also, a -1 to both the “separate / do not separate” proposals. I think it’s focusing on completely the wrong thing. We shouldn’t say how to use OAuth or GNAP apart from the following very limited things:

 - say you can use an access token (either bound or bearer depending on your use case)
 - give a description of what you can ask for at this API (this is what RAR gives you, and would work with both OAuth2 and GNAP)

… and that’s it. Don’t say anything about grant types, especially client credentials. Don’t say anything about token formats or introspection. Don’t say anything about token contents. Don’t say anything about client types and deployments. 

It seems to be that I keep suggesting this one thing and the group keeps reacting negatively to something else that I have — many times — explicitly said not to do, and yet assigning that negative reaction to what I’m proposing. I am genuinely at a loss of how to clear up this confusion at this stage, but hopefully the above helps.

 — Justin

Received on Monday, 12 July 2021 15:31:49 UTC