- From: Joe Andrieu <joe@legreq.com>
- Date: Sun, 22 Aug 2021 11:48:08 -0700
- To: "Credentials Community Group" <public-credentials@w3.org>
- Message-Id: <b3c1d878-7356-40bb-b77b-cc46b3e9ad8a@www.fastmail.com>
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 18:48:45 UTC