Re: Proposal for Authorization in VC HTTP API

On Sun, Aug 22, 2021 at 11:50 AM Joe Andrieu <joe@legreq.com> wrote:

>
> In the VC work, we established fairly early on that "verify" means
> checking the proofs and status, and nothing more. "Validation" followed
> verification to validate the proofed claims against business rules (such as
> acceptable issuers for a given class of assertions). The term for "valid"
> in the sense of "well-formed" largely became "conformant", since "valid"
> has distinct meaning in nearby domains such as XML. So, "conformant" has
> largely become this community's term for this first sense of authenticate.
>

"Conformant" works for me.

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


On Sun, Aug 22, 2021 at 11:50 AM Joe Andrieu <joe@legreq.com> wrote:

> On Sun, Aug 22, 2021, at 10:34 AM, Alan Karp wrote:
>
> 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.
>
>
> In the VC work, we established fairly early on that "verify" means
> checking the proofs and status, and nothing more. "Validation" followed
> verification to validate the proofed claims against business rules (such as
> acceptable issuers for a given class of assertions). The term for "valid"
> in the sense of "well-formed" largely became "conformant", since "valid"
> has distinct meaning in nearby domains such as XML. So, "conformant" has
> largely become this community's term for this first sense of authenticate.
>
> However, for the second sense, I suggest a slight adjustment (which I
> believe is aligned with your intent, Alan). I find myself resonating with
> Manu's framing:
>
> On Sun, Aug 22, 2021, at 7:10 AM, Manu Sporny wrote:
>
> "yes, that's the john smith we know" is authentication
>
>
> To my mind, authentication is always about proving, *within a system of
> identification*, that the other party in a current session one we can
> recognize. In general, that means performing whatever authentication dance
> the system requires to establish a binding to an acceptable identifier. For
> "legacy" systems that means providing a password for a given username, or
> in many cases, just providing a cookie. For cryptography, that means
> proving the ability to solve a cryptographic challenge, usually requiring
> knowledge of one or more secrets. For DID Auth, that means proving control
> over a DID. Some systems require elevated authentication for some tasks for
> extra assurance that the current session is with a recognizable party. For
> example, two-factor authentication is one of those means used to generate
> extra assurance. That's authentication as I believe we mean it. (And it
> works for "session" broadly, included sessions in the past or future.)
>
> My push back on your specific language, is simply is that no
> authentication system can fully answer if "this is the right person", even
> when it is trying to. The best one can do is "given the mechanisms we
> accept, the current session/user/account has demonstrated they are, to the
> best of our ability to tell, a party we recognize."
>
> My pedantry on this point is because "identity" has been seen as a
> cure-all for many security threats, but in fact, we rarely can definitively
> prove, in an electronic system, that any particular human body is involved
> in an interaction. [Note this sense of "identity", aka the
> space-time-continuity mental model, has its own drawbacks]. Every
> identification system
>
> 1. makes certain assumptions
> 2. has fallback mechanisms to compensate when those assumptions fail
> 3. has known attack vectors
> 4. unknown attack vectors
>
> IMO, we should steer away from ideas of computational knowledge that a
> party "is the right person" if we want to produce more secure systems. That
> helps avoid the blinders that sometimes occur when we build systems with
> the belief that "identity" is a computationally solvable problem.
>
> -j
>
> 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.
>
> --------------
> 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
>
>
>
>
> --
> Joe Andrieu, PMP
>                    joe@legreq.com
> LEGENDARY REQUIREMENTS
>    +1(805)705-8651
> Do what matters.
>                  http://legreq.com <http://www.legendaryrequirements.com>
>
>
>