Re: Proposal for Authorization in VC HTTP API

On Sun, Aug 22, 2021 at 11:10 AM David Chadwick <
d.w.chadwick@verifiablecredentials.info> wrote:

> On 22/08/2021 18:34, Alan Karp wrote:
>
> On Sun, Aug 22, 2021 at 9:25 AM David Chadwick <
> d.w.chadwick@verifiablecredentials.info> wrote:
>
> 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.
>
> I have been very happy to see the term "verify" used in this discussion,
> because it avoids the confusion between "authenticate" to mean "this is a
> properly formed token" from "this is the right person."  Your last phrase
> raises the possibility of someone taking "authenticate" in a way you didn't
> intend.
>
> authenticate:  to establish as genuine (dictionary.com).
>
> nothing more, nothing less :-)
>
You are 100% correct, but people too often take "authenticate" to mean
"verify the identity of the requester."  I prefer that the verification
process implicitly include the step of establishing the token as genuine to
avoid this confusion.

--------------
Alan Karp


On Sun, Aug 22, 2021 at 11:10 AM David Chadwick <
d.w.chadwick@verifiablecredentials.info> wrote:

> On 22/08/2021 18:34, Alan Karp wrote:
>
> On Sun, Aug 22, 2021 at 9:25 AM David Chadwick <
> d.w.chadwick@verifiablecredentials.info> wrote:
>
> 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.
>
> I have been very happy to see the term "verify" used in this discussion,
> because it avoids the confusion between "authenticate" to mean "this is a
> properly formed token" from "this is the right person."  Your last phrase
> raises the possibility of someone taking "authenticate" in a way you didn't
> intend.
>
> authenticate:  to establish as genuine (dictionary.com).
>
> nothing more, nothing less :-)
>
> David
>
>
> --------------
> Alan Karp
>
>
> On Sun, Aug 22, 2021 at 9:25 AM David Chadwick <
> d.w.chadwick@verifiablecredentials.info> wrote:
>
>> On 22/08/2021 15:10, Manu Sporny wrote:
>>
>> On 8/21/21 7:26 PM, steve capell wrote:
>>
>> * I'm unclear about which VC-API interactions should require authorisation
>> and which should not.
>>
>> There is clarity on most, but not all, of the endpoints we have defined so far
>> wrt. authorization. There is a column here marked "Authorization Required?":
>> https://docs.google.com/spreadsheets/d/1hlevKRxCXsJBWvJTkL30nZVp8cpF26aY3PJqzuHtIZE/edit#gid=0
>>
>> To be clear, we're talking exclusively about authorization (not
>> authentication, e.g., DIDAuth -- that's out of scope).
>>
>>
>> * I can imagine that an issuer will certainly want to authorise a subject
>> that is requesting a VC.  "yes, that's the john smith we know, here's your
>> digital drivers license"
>>
>> The term I believe you meant to use was "authenticate", because
>> "authorization" is subtly orthogonal. So, let's make sure we're talking about
>> the same thing first:
>> https://stackoverflow.com/a/6556548
>>
>> "yes, that's the john smith we know" is authentication
>>
>> "and given that it's the john smith we know, he is authorized to receive a
>> digital driver's license" is authorization.
>>
>> "here's your digital drivers license" presumes some sort of authorization took
>> place. Providing the digital drivers license happens AFTER authorization was
>> successful.
>>
>>
>> * But I cant imagine why or how a verifier will want to authorise John
>> when he presents his license as proof of age in a bottle shop because
>> there's very unlikely to have been any a-priori registration of either john
>> or his chosen system to the bottle shop system. Instead I'd expect an
>> anonymous access "yes, that's a valid drivers license and, yes, the photo
>> on it looks like you sir, here's your vodka".
>>
>> Again, "yes, that's a valid drivers license and, yes, the photo on it looks
>> like you sir" is authentication.
>>
>> "and given that you're above the age of ??, you are allowed to purchase
>> alcohol" is authorization.
>>
>> "here's your vodka" presumes some sort of authorization took place.
>>
>> You're not far off, but we do need to make sure we're very clear about what
>> we're talking about "authorization", and what's not necessarily the focus of
>> the current discussion "authentication".
>>
>>
>> would it be possible to see a diagram of VC-API interactions with some
>> indication of which require auth and which dont?
>>
>> Column G here:
>> https://docs.google.com/spreadsheets/d/1hlevKRxCXsJBWvJTkL30nZVp8cpF26aY3PJqzuHtIZE/edit#gid=0
>>
>> The Use Cases team is working on some more detailed data flow diagrams to
>> elaborate upon the matter further. I expect we're several weeks of from those
>> being done.
>>
>> Did that help, Steve?
>>
>> 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.
>>
>> -- manu
>>
>>
>>
>> authenticate
>