- From: Alan Karp <alanhkarp@gmail.com>
- Date: Sun, 22 Aug 2021 12:26:15 -0700
- To: Joe Andrieu <joe@legreq.com>
- Cc: Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CANpA1Z2Oh_p2+6MZvOcL9ds8YitcDdvECC8ECgFbiB=5obBb3Q@mail.gmail.com>
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> > > >
Received on Sunday, 22 August 2021 19:27:41 UTC