Re: Create GNAP authorization specification for VC HTTP API (was: Re: Request for CCG Chair Intervention in CCG Process)

Hi David,

You said this:

On 8/22/21 12:19 PM, David Chadwick wrote:
> I was proposing that the separate document be an  authorisation document 
> for the HTTP API, saying which authorisation mechanisms may, should or must
> be used. So that the HTTP API can concentrate on the functionality of the
> API, assuming that another document will describe the authentication and
> authorisation mechanism(s).

... and then you said this:

> Surely the http api should concentrate on the functionality of the 
> endpoints, and authentication and authorisation is required for all of 
> them, which can be the subject of the new document that Orie is suggesting.
> I also assume that using the term authorisation implies authentication as
> well, since you cannot authorise anyone without authentication e.g. I
> present an authz token to you, but you still have to authenticate and
> verify the token.

... and all of that together confused me. Let me try to expand each concern below:

> I was proposing that the separate document be an  authorisation document 
> for the HTTP API, saying which authorisation mechanisms may, should or must
> be used.

This will almost certainly re-create the same issue we have now, where people
are fighting over OAuth2 Client Credentials and GNAP/RAR in the same document. It
just shifts the exact same discussion to a separate document where the same
conversation we've been having will play out again.

I believe Orie is saying -- "separate the GNAP portion out and put it in
another specification, on another call". He'll have to clarify what he meant
before we can chase this down any further.

> Surely the http api should concentrate on the functionality of the 
> endpoints, and authentication and authorisation is required for all of 
> them

That is not clear at this point. I don't think we can make the statement that
"surely authn/authz is required for all VC HTTP API endpoints". Some may be
completely unauthenticated (in order to get a response) -- e.g., Search
engines don't authenticate or authorize you before they return search results
to you. The presentation APIs fall into this category of "no authn/authz
necessary". See why your assumption might not hold here:

https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0318.html

>> I also assume that using the term authorisation implies authentication as
>> well, since you cannot authorise anyone without authentication e.g. I 
>> present an authz token to you, but you still have to authenticate and 
>> verify the token.

I think it might be confusing to use the word "authentication" in the way that
you are. I think I know what you're saying, which is "One needs to determine
that an authorization token *is authentic* to allow the request to proceed."

If we were to put this into a set of steps, it would be:

1. Client authenticates in order to receive an
   authorization token of some kind.
2. Client performs a request to the VC HTTP API with the
   authorization token.
3. Server determines if the authorization token is
   valid and either allows or deny's the request.

As far as I've heard so far, step #1 and #3 is out of scope for the VC HTTP
API, and step #2 is in scope for the VC HTTP API. That is, "We don't care how
you got your authorization token, or how the server determines if it's good
enough for the operation being performed... but we do care about what types of
authorization tokens you can provide because we can't achieve interoperability
w/o defining at least one mechanism."

At this point, I think you and Orie are asking for different things, David.
Did I misunderstand anything?

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/

Received on Sunday, 22 August 2021 17:04:48 UTC