Re: [GNAP] Will GNAP support Zero Trust Architecture?
Denis <denis.ietf@free.fr> Thu, 25 March 2021 15:34 UTC
Return-Path: <denis.ietf@free.fr>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E463A2598 for <txauth@ietfa.amsl.com>; Thu, 25 Mar 2021 08:34:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.018
X-Spam-Level:
X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C14GKmYqwkdy for <txauth@ietfa.amsl.com>; Thu, 25 Mar 2021 08:34:43 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF773A25E4 for <txauth@ietf.org>; Thu, 25 Mar 2021 08:34:38 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.53.231]) by mwinf5d39 with ME id kfaW2400H4zJUWJ03faWmn; Thu, 25 Mar 2021 16:34:34 +0100
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 25 Mar 2021 16:34:34 +0100
X-ME-IP: 90.79.53.231
To: Adrian Gropper <agropper@healthurl.com>, Justin Richer <jricher@mit.edu>
Cc: Alan Karp <alanhkarp@gmail.com>, Fabien Imbault <fabien.imbault@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>, Mark Miller <erights@gmail.com>, GNAP Mailing List <txauth@ietf.org>
References: <CANYRo8jBZFVWyvAgVSWSmnuC+i1NaEkJEGWextzGB0xNFnD9fA@mail.gmail.com> <CAM8feuSGR58Y1a0ta5EQThwDeRJfXNLehYe_zhBqvhu+8tDzPg@mail.gmail.com> <CANYRo8gbTuDYHDHaR=y4cWOimYWqptEOYD6UbsbCpdd0Rh6QHQ@mail.gmail.com> <CAM8feuTLG5n+=GFb_Mdb1_fD3YAvSHsJiUrFCp7O+-tP-xzbfQ@mail.gmail.com> <CAM8feuSxttFqra9JpXXSKMqfmGUhz30+3eDQRtDpKPF-4pVmbQ@mail.gmail.com> <CANYRo8iJfpF2nt4se3KNhe14B5c_+ndmwjFFAhw7ybnJa_Cq2A@mail.gmail.com> <CAM8feuS0YOWC-wpz=0GP1x-7EV6fdx0puimkS6AXJP=ZtYM8aA@mail.gmail.com> <CANYRo8hQjcEWrwK=scpopVSnzYQ6AiObk2RoLSS+U=V1jxo1EQ@mail.gmail.com> <CAM8feuT+noLdtUYaUGfzhezTea+Uy6+9xWfb814TOg4w0u_tOA@mail.gmail.com> <CANYRo8hHUqSoDHjGRpm6qZLSm=3rd8E5OEFjreDvDyMvjHOdUw@mail.gmail.com> <CAM8feuTJawB+msiSrYUeen15eHLDcOzD4diy6++DNoYYcHqMug@mail.gmail.com> <CAM8feuTqMXF4b+ZaEJpkfeTJeBsuf227VNC3p1sDGJByFUn8jA@mail.gmail.com> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <CANYRo8gLnjLYAOg5ToJ6RJEWeC=Vq9w2wHnZzEwM=3sr=1Go8g@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <1d9d5bed-32ff-a864-85a5-a16ee6063802@free.fr>
Date: Thu, 25 Mar 2021 16:34:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <CANYRo8gLnjLYAOg5ToJ6RJEWeC=Vq9w2wHnZzEwM=3sr=1Go8g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------CAA159ACB28604E87B5096F3"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/NVnZyFQDSgBI83W-rrBjfAQb4jM>
Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture?
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Mar 2021 15:34:51 -0000
Since there is still no definition to explain what mean the acronyms AS-RO and AS-RS, I have created my own terminology */RO-AS/* and */RO-RS/* and wrote a full story including the definitions of a RO-AS and RO-RS. See the issue #223 https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 Denis > Thanks for the summary Justin. You very clearly articulated what I > would call the "regulatory capture" aspects of the problem. The RS > will do everything they can to avoid ceding power to the RO. By > avoiding standards that shift power to the RO, the platforms, IdP's, > and most other service providers delay regulation that would promote > agent-based delegated access to an API as a human right. > > It's only recently, with GDPR, that lawmakers have started to consider > human rights outside of healthcare and are now introducing concepts > such as the separation of controller from processor in order to enable > a new generation of regulation. My perspective on GNAP is not > arbitrary. It is honed by years of experience in healthcare as > everyone struggles with OAuth and OpenID Connect, HEART, and now UDAP, > to avoid doing in standards what seems obvious from a human rights > perspective. > > What's interesting is that the "regulatory capture" standards game is > now playing out in a new arena. The recent transition of DID to W3C > Candidate Recommendation, together with Verifiable Credentials before > that, means that every regulator (e.g. US Health and Human Services, > Scotland, EU...) and some legislatures (e.g. Wyoming) are having to > deal with the concept of Self-Sovereign Identity. It's not fun for the > community that has worked so hard on SSI to now have to dance-around > the actual impact of the SSI standards. > > With VC and DID, W3C seems to have broken through a "regulatory > capture" barrier and that community is moving on to standardize > protocols like DIDcomm and Encrypted Data Vaults that may avoid > delegated authorization as a human right. In my opinion, GNAP, and > IETF, is facing the same "regulatory capture" barrier. > > Justin says: "Of course, market forces being as they are, I might not > have much of an actionable choice in RS, but GNAP can’t change that." > What GNAP makes core can change the choices the market offers by > making GNAP an interoperability badge that stands for Human-Centered > Protocol. If GNAP moves the human-centered part to an extension, then > we're no better than another "profile" on top of OAuth. > > Adrian > > On Thu, Mar 25, 2021 at 8:46 AM Justin Richer <jricher@mit.edu > <mailto:jricher@mit.edu>> wrote: > > The way I’m thinking about Adrian’s use case is that what we’re > calling the “AS-RO” isn’t an “AS” in the traditional OAuth/GNAP > sense, at least not exactly. This is the agent that the RO can use > to set policies and manage consent on their behalf, and I’ve been > arguing that it fits better into this vaguely-defined “interaction > component” aspect of the current AS definition, and it’s not > currently separated from the AS definition. The “AS-RS” maps to > what we’d call the “AS” in OAuth/GNAP traditionally, it’s what the > RS trusts to issue tokens. In traditional OAuth the AS-RO and > AS-RS are always the same thing, from a functional protocol > perspective. An important point here is that from a client’s > perspective, they’re only talking to the AS-RS since that’s where > the client gets its tokens, because at the end of the day the > client just wants to call the API at the RS and doesn’t care how > that happens (from a protocol standpoint). > > Note well: Even thought I don’t believe that “AS-RO” is an > authorization server at all, I’m going to keep using that term > below for consistency with previous discussion. > > So we have these fundamental relationships around getting the > client to access the RS: > > 1. RS trusts AS-RS to issue tokens that RS will accept, validate, > and process for requests from client > 2. Client trusts AS-RS to issue tokens that client can use at RS > 3. RO trusts RS to protect RO’s api through delegated access > > On top of that, we’ve got some additional aspects that we’re > discussing: > > 4. RO trusts AS-RO to manage RO’s policies at runtime > 5. AS-RS trusts AS-RO to assert RO’s policies for access to RS > 6. Client trusts whatever AS-RS sends client to deal with, > including possibly RO-AS at runtime, because of (2) > > What I have been saying is that 4/5/6 are optional details of how > RS-AS runs things, and I think this also maps with Adrian’s view > of choice, since if my RS’s AS-RS doesn’t allow me to plug in my > own AS-RO then I would be motivated to pick a different RS who’s > AS-RS lets me do just that. The same way I’d pick a different RS > if their surrounding services didn’t accept my preferred > federation login and I didn’t want to make another account. Of > course, market forces being as they are, I might not have much of > an actionable choice in RS, but GNAP can’t change that. > > What we can do is make it possible for AS-RS to talk to AS-RO, > both in philosophy of the protocol design and in concrete hooks to > support (6) above. > > Separately, we can approach the issue of making 1/2 above more > dynamic. This was UMA2’s “federated authorization” approach, and > is behind a lot of the “bring your own AS” models out there. The > problem with these is that we know from many years of experience > that most RS’s aren’t interested in doing anything of the sort. > > So with GNAP we can instead allow 4/5/6 to vary in a predictable > and consistent way, letting the RS keep control over 1/2, thereby > enabling choice in (3). We don’t have to be the ones who define > the all of the details of every permutation of (5) to enable this, > though. Some of this is going to be configuration out of band, > some of it’s going to be communication at runtime. This is where > VC’s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of other tech > can come in and help out. I don’t think we need to put all the > details for using these into core, nor do I think we’ll pull of > The Great And Ultimate Abstraction for using these and other > approaches. But we can at least start talking about “AS-RS” in > such a way that it no longer assumes it’s always the same party > dealing with the RO directly. > > — Justin > >> On Mar 25, 2021, at 6:40 AM, Fabien Imbault >> <fabien.imbault@gmail.com <mailto:fabien.imbault@gmail.com>> wrote: >> >> To reframe it closer to GNAP: >> - AS = AS-RO, that's where you find the RO policies. The AS >> issues access tokens to the client. >> - the RO policies could be a) defined locally or b) in >> relationship with the RS >> >> There have been several ideas related to the AS-RS relationship b: >> b1) the RS issues capabilities (which can be further attenuated >> by the RO) >> b2) Adrian also discussed a DID based solution >> b3) there was also an alternative ACL proposal from Denis (+ >> preflight) >> >> Fabien >> >> >> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault >> <fabien.imbault@gmail.com <mailto:fabien.imbault@gmail.com>> wrote: >> >> Ok so I get you correctly: >> - what matters is the RQ (could be a RO or a end-user or both >> : we don't really care at a high-level, they're all treated >> as entities that make a request) >> - the policy is able to handle those different cases, based >> on its own internal delegation protocol >> - currently that requires AS-RS and AS-RO, but maybe it can >> be simplified >> >> To answer to Denis, here's what I understood: >> - RO trusts AS-RS (and then handles its own policies within >> AS-RO) >> - end-user trusts AS-RO (through its client) >> >> Could probably work but that's a fairly different model >> compared to OAuth2 (and of today's GNAP), with different >> frontiers between the AS and the RS. >> >> Please do not hesitate to correct me if I'm wrong. >> >> Fabien >> >> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper >> <agropper@healthurl.com <mailto:agropper@healthurl.com>> wrote: >> >> I believe there are alternatives to having two kinds of >> ASs. The problem may be a side-effect of deciding to >> switch away form treating the RO as different from the >> RQ. That leads to downstream privacy issues. Our desire >> for architectural simplicity is admirable but that may >> have been a step too far. >> >> There may also be solutions based on different types of >> tokens, as in different capabilities (tokens signed by >> the RS) vs. tokens signed by the AS. I’m not sure about >> that but Alan might have more to say. >> >> Adrian >> >> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault >> <fabien.imbault@gmail.com >> <mailto:fabien.imbault@gmail.com>> wrote: >> >> Thanks. The general problem statement is clear. >> >> The proposed solution a bit less (to me). I >> understood that from point 2, Alan involves 2 ASs. >> You said : "There’s no obvious reason to have two >> types of ASs". Do you see an alternative ? >> >> Regarding the last item, I don't think that naming RQ >> by end-user created the problem. It might just >> highlight the asymmetry, which fundamentally exists. >> >> Fabien >> >> >> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper >> <agropper@healthurl.com >> <mailto:agropper@healthurl.com>> wrote: >> >> Recap: >> 1 - Justin (I think) introduced the idea of an AS >> on the RS trust boundary side. >> 2 - I said the RO should not have to share >> policies with the RS. >> 3 - Alan invented the concept of AS-RO and AS-RS >> to separate two kinds of PDPs. >> >> The thing is that step 2 is not symmetrical. The >> RO has a legitimate privacy interest in keeping >> their policies private and minimizing the leakage >> of information about requests that are posed >> against those policies. >> >> The RS, on the other hand, should be publishing >> its policies (e.g. what it’s selling or what >> jurisdiction it’s in or what tokens or scopes it >> supports). The RS has no obvious privacy interest >> in GNAP. It’s just an enforcer. >> >> There is one other privacy interest to consider >> around the RS and that is the requesting party >> (the end-user that is not the RO :-) might prefer >> to share attributes with the RS instead of the RO >> or something controlled by the RO. This case >> could be an “extension” to GNAP and might result >> in a split AS as a solution. This problem was >> introduced when the editors decided to replace RQ >> with end-user. Obviously, the RO end-user has no >> privacy interests relative to itself. >> >> Adrian >> >> >> >> >> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault >> <fabien.imbault@gmail.com >> <mailto:fabien.imbault@gmail.com>> wrote: >> >> I was referring to "By my definition, this >> model has two ASs since both are processing >> requests into tokens". If there's no reason >> to have 2 types of ASs, that's fine then. >> But I'm a bit lost in where we stand with the >> idea. >> >> Could you recap? >> >> Fabien >> >> Le jeu. 25 mars 2021 à 08:16, Adrian Gropper >> <agropper@healthurl.com >> <mailto:agropper@healthurl.com>> a écrit : >> >> There’s no obvious reason to have two >> types of ASs. Any AS that is executing >> the policies of the RS can look to GNAP >> like the RS itself. Why would GNAP expose >> that interface to anyone? >> >> Adrian >> >> On Thu, Mar 25, 2021 at 3:11 AM Fabien >> Imbault <fabien.imbault@gmail.com >> <mailto:fabien.imbault@gmail.com>> wrote: >> >> Note : I'm not sure that's a good >> idea, but having 2 types of ASs is >> not that easy to grasp. >> >> Fabien >> >> Le jeu. 25 mars 2021 à 08:07, Fabien >> Imbault <fabien.imbault@gmail.com >> <mailto:fabien.imbault@gmail.com>> a >> écrit : >> >> The purpose of either handling >> policies locally or delegating >> them to the RO agent. >> >> Le jeu. 25 mars 2021 à 08:04, >> Adrian Gropper >> <agropper@healthurl.com >> <mailto:agropper@healthurl.com>> >> a écrit : >> >> What purpose would be served >> by GNAP splitting the AS into >> two components? >> >> Adrian >> >> On Thu, Mar 25, 2021 at 2:59 >> AM Fabien Imbault >> <fabien.imbault@gmail.com >> <mailto:fabien.imbault@gmail.com>> >> wrote: >> >> Isn't the AS-RO a >> component of the AS? Same >> idea as the interact >> component, it >> functionnally belongs to >> the AS role but could be >> deployed either as a >> monolith or as a separate >> component? >> >> Fabien >> >> Le jeu. 25 mars 2021 à >> 04:26, Adrian Gropper >> <agropper@healthurl.com >> <mailto:agropper@healthurl.com>> >> a écrit : >> >> Yes, but I would say >> it’s not the RO that >> wants the access >> token. It’s the RO >> that wants the client >> making the request to >> get an access token. >> >> Adrian >> >> On Wed, Mar 24, 2021 >> at 11:22 PM Alan Karp >> <alanhkarp@gmail.com >> <mailto:alanhkarp@gmail.com>> >> wrote: >> >> Adrian Gropper >> <agropper@healthurl.com >> <mailto:agropper@healthurl.com>> >> wrote: >> >> >> In this >> design, the >> AS is the >> AS-RS and the >> agent is the >> AS-RO. By my >> definition, >> this model >> has two ASs >> since both >> are >> processing >> requests into >> tokens. The >> problem with >> this is >> complexity >> and privacy. >> The RO may >> not want to >> share the >> request >> information >> with the AS-RS. >> >> >> More precisely, >> RO has no choice >> but to present >> the required >> information to >> AS-RS if RO wants >> an access token. >> However, RO does >> not want AS-RS to >> know the policy >> by which RO >> delegates tokens. >> That's why RO >> uses AS-RO for >> those delegations. >> >> -------------- >> Alan Karp >> >> >> On Wed, Mar 24, >> 2021 at 7:41 PM >> Adrian Gropper >> <agropper@healthurl.com >> <mailto:agropper@healthurl.com>> >> wrote: >> >> Thank you for >> creating the >> issue. My >> definition of >> AS is >> independent >> of AS-RO or >> AS-RS. >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421 >> <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421> >> I also agree >> with Alan's >> definition >> based on >> delegation. >> An AS-RS >> would be a >> delegate of >> the RS. >> >> Based on >> that, I see >> it as >> obvious that >> the policy >> has to be >> accessible >> (defined >> locally?) in >> order for it >> to be run as >> the code that >> turns a >> request into >> an access token. >> >> The only >> other >> possibility >> is that the >> request is >> packaged by >> the AS and >> sent >> elsewhere (an >> agent) for >> evaluation >> against >> policy and a >> proto-token >> returned. In >> that case the >> AS is acting >> as a proxy >> and the PDP >> is elsewhere. >> I can imagine >> that an AS-RS >> would behave >> this way so >> that the >> proto-token >> could be >> turned into >> an access >> token by the >> AS-RS. Isn't >> this what >> Justin is >> proposing? In >> this design, >> the AS is the >> AS-RS and the >> agent is the >> AS-RO. By my >> definition, >> this model >> has two ASs >> since both >> are >> processing >> requests into >> tokens. The >> problem with >> this is >> complexity >> and privacy. >> The RO may >> not want to >> share the >> request >> information >> with the AS-RS. >> >> Adrian >> >> On Wed, Mar >> 24, 2021 at >> 5:21 PM >> Fabien >> Imbault >> <fabien.imbault@gmail.com >> <mailto:fabien.imbault@gmail.com>> >> wrote: >> >> Isn't >> that what >> the AS is >> supposed >> to be, >> only with >> the >> caveat >> that the >> policy is >> defined >> locally? >> >> Fabien >> >> >> Le mer. >> 24 mars >> 2021 à >> 20:17, >> Alan Karp >> <alanhkarp@gmail.com >> <mailto:alanhkarp@gmail.com>> >> a écrit : >> >> AS-RO >> is an >> AS >> that >> RO >> trusts >> to >> delegate >> RO's >> access >> tokens >> according >> to >> RO's >> policies. >> >> >> -------------- >> Alan Karp >> >> >> On >> Wed, >> Mar >> 24, >> 2021 >> at >> 9:36 >> AM >> Fabien >> Imbault >> <fabien.imbault@gmail.com >> <mailto:fabien.imbault@gmail.com>> >> wrote: >> >> Hi >> Alan >> and >> Adrian, >> >> >> I've >> created >> issue >> AS-RO >> policy >> delegation >> (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 >> <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223>) >> to >> capture >> your >> input. >> >> A >> first >> question >> that >> arises: >> can >> we >> give >> a >> definition >> to >> AS-RO? >> >> Thanks >> Fabien >> >> On >> Tue, >> Mar >> 23, >> 2021 >> at >> 4:15 >> PM >> Alan >> Karp >> <alanhkarp@gmail.com >> <mailto:alanhkarp@gmail.com>> >> wrote: >> >> Fabien >> Imbault >> <fabien.imbault@gmail.com >> <mailto:fabien.imbault@gmail.com>> >> wrote: >> >> Hi >> Alan, >> >> >> Yes, >> but >> in >> that >> flow, >> the >> token >> relationship >> between >> AS-RS >> and >> AS-RO >> is >> only >> secure >> if >> the >> tokens >> issued >> by >> AS-RS >> are >> cryptographically >> attenuable >> in >> the >> first >> place. >> >> >> Attenuated >> delegation >> is >> a >> requirement, >> but >> that >> doesn't >> have >> to >> be >> done >> cryptographically. >> Token >> exchange >> works >> just >> fine. >> SPKI >> and >> zcap-ld >> are >> examples >> of >> the >> crypto >> approach, >> and >> we >> used >> token >> exchange >> in >> the >> system >> for >> HP. >> >> -------------- >> Alan >> Karp >> >> >> On >> Tue, >> Mar >> 23, >> 2021 >> at >> 4:12 >> AM >> Fabien >> Imbault >> <fabien.imbault@gmail.com >> <mailto:fabien.imbault@gmail.com>> >> wrote: >> >> Hi >> Alan, >> >> >> Yes, >> but >> in >> that >> flow, >> the >> token >> relationship >> between >> AS-RS >> and >> AS-RO >> is >> only >> secure >> if >> the >> tokens >> issued >> by >> AS-RS >> are >> cryptographically >> attenuable >> in >> the >> first >> place. >> >> >> Fabien >> >> On >> Mon, >> Mar >> 22, >> 2021 >> at >> 9:26 >> PM >> Alan >> Karp >> <alanhkarp@gmail.com >> <mailto:alanhkarp@gmail.com>> >> wrote: >> >> Justin >> Richer >> <jricher@mit.edu >> <mailto:jricher@mit.edu>> >> wrote: >> >> >> But >> with >> all >> that >> in >> mind, >> I >> think >> the >> key >> here >> is >> going >> to >> be >> looking >> at >> what >> the >> inputs >> to >> the >> AS >> are, >> and >> how >> those >> can >> be >> defined >> in >> an >> interoperable >> way >> for >> AS’s >> that >> can >> accept >> them. >> I >> think >> there’s >> a >> lot >> of >> room >> for >> innovation >> and >> flexibility >> here >> that >> doesn’t >> break >> the >> trust >> model >> or >> core >> use >> cases. >> If >> I >> have >> an >> AS-RS >> set >> that >> won’t >> accept >> my >> favorite >> flavor >> of >> policy >> engine >> inputs, >> then >> I >> can >> decide >> not >> to >> use >> that >> one. >> But >> this >> is >> a >> very >> different >> question >> than >> saying >> the >> RS >> itself >> needs >> to >> accept >> my >> own >> AS >> — >> and >> we >> can’t >> keep >> conflating >> these >> two >> models. >> >> I >> agree. >> The >> point >> of >> having >> an >> AS-RO >> is >> to >> allow >> RO >> to >> specify >> a >> policy >> for >> which >> of >> RO's >> access >> tokens >> should >> be >> delegated >> under >> what >> conditions. >> AS-RS >> should >> not >> need >> to >> understand >> those >> policies. >> The >> flow >> would >> be >> >> * RO >> contacts >> AS-RS >> and >> gets >> one >> or >> more >> access >> tokens. >> * RO >> delegates >> one >> or >> more >> of >> those >> tokens, >> potentially >> sub-scoped, >> to >> AS-RO. >> * A >> different >> user >> contacts >> AS-RO >> to >> get >> a >> potentially >> sub-scoped >> access >> token >> from >> AS-RO. >> * That >> user >> presents >> the >> access >> token >> delegated >> by >> AS-RO >> when >> invoking >> the >> resource. >> >> AS-RS >> only >> needs >> to >> verify >> that >> the >> delegation >> chain >> is >> legitimate, >> e.g., >> no >> increase >> in >> scope, >> and >> that >> it >> grants >> permission >> for >> the >> request >> being >> made. >> AS-RS >> does >> not >> need >> to >> understand >> the >> policy >> behind >> granting >> the >> delegation >> by >> AS-RO. >> >> -------------- >> Alan >> Karp >> >> >> On >> Mon, >> Mar >> 22, >> 2021 >> at >> 11:40 >> AM >> Justin >> Richer >> <jricher@mit.edu >> <mailto:jricher@mit.edu>> >> wrote: >> >> Adrian, >> >> >> I >> think >> this >> shows >> the >> problem >> with >> the >> terminology >> as >> it’s >> been >> applied >> in >> this >> conversation, >> which >> I’ve >> tried >> to >> shine >> light >> on >> before. >> What >> you >> and >> others >> are >> calling >> the >> “RS” >> is >> really >> the >> “AS >> and >> RS >> working >> together” >> — >> everything >> to >> the >> right >> of >> the >> line. >> When >> Denis >> had >> brought >> up >> “eliminating >> the >> AS” >> in >> another >> thread, >> what >> he’d >> really >> done >> is >> labeled >> everything >> to >> the >> right >> of >> the >> line >> as >> the >> “RS”. >> Of >> course, >> the >> irony >> here >> is >> that >> everything >> to >> the >> right >> of >> the >> line >> used >> all >> be >> called >> the >> “AS” >> or >> simply >> “server” >> in >> the >> OAuth >> 1 >> days. >> As >> you >> say >> below, >> I >> don’t >> want >> the >> client >> to >> have >> visibility >> on >> what >> happens >> on >> that >> side. >> >> >> Note >> well: >> The >> Google+ >> logo >> labeled >> “IdP” >> in >> the >> diagram >> is >> not >> the >> AS, >> as >> far >> as >> GNAP >> is >> concerned. >> It >> does >> not >> issue >> an >> access >> token >> that >> the >> RS >> will >> accept. >> The >> elements >> to >> the >> left >> of >> the >> line >> could >> be >> a >> lot >> of >> things, >> but >> they >> are >> NOT >> the >> AS >> — >> by >> definition. >> The >> client >> lives >> over >> on >> the >> left, >> but >> so >> do >> any >> external >> inputs >> to >> the >> AS. >> These >> could >> be >> policy >> inputs >> on >> behalf >> of >> the >> RO, >> they >> could >> be >> presentation >> artifacts, >> they >> could >> be >> federated >> logins, >> they >> could >> be >> the >> output >> of >> policy >> decisions. >> How >> the >> AS >> comes >> to >> trust >> those >> things >> is >> up >> to >> the >> AS’s >> implementation. >> It’s >> something >> we >> can >> talk >> about, >> but >> ultimately >> GNAP >> won’t >> be >> in >> any >> position >> to >> dictate >> because >> in >> practice >> some >> AS’s >> are >> simply >> going >> to >> internalize >> all >> policies >> and >> we >> will >> never >> successfully >> force >> those >> open. >> >> >> But >> with >> all >> that >> in >> mind, >> I >> think >> the >> key >> here >> is >> going >> to >> be >> looking >> at >> what >> the >> inputs >> to >> the >> AS >> are, >> and >> how >> those >> can >> be >> defined >> in >> an >> interoperable >> way >> for >> AS’s >> that >> can >> accept >> them. >> I >> think >> there’s >> a >> lot >> of >> room >> for >> innovation >> and >> flexibility >> here >> that >> doesn’t >> break >> the >> trust >> model >> or >> core >> use >> cases. >> If >> I >> have >> an >> AS-RS >> set >> that >> won’t >> accept >> my >> favorite >> flavor >> of >> policy >> engine >> inputs, >> then >> I >> can >> decide >> not >> to >> use >> that >> one. >> But >> this >> is >> a >> very >> different >> question >> than >> saying >> the >> RS >> itself >> needs >> to >> accept >> my >> own >> AS >> — >> and >> we >> can’t >> keep >> conflating >> these >> two >> models. >> >> So >> to >> me, >> GNAP >> can >> support >> a >> Zero >> Trust >> Architecture >> by >> LEVERAGING >> the >> AS, >> not >> by >> subsuming >> or >> eliminating >> it. >> It >> is >> in >> fact >> the >> AS, >> not >> the >> client >> and >> not >> the >> RS, >> that >> will >> request >> and >> consume >> the >> results >> of >> a >> privacy-preserving >> zero-trust >> policy >> query >> thing. >> Anything >> that >> happens >> downstream >> from >> that >> is >> of >> little >> concern >> to >> the >> zero-trust >> components >> because, >> as >> you >> point >> out, >> it’s >> on >> the >> “other >> side” >> of >> the >> line. >> >> >> I >> think >> we >> got >> this >> basic >> component >> model >> pretty >> right >> in >> OAuth: >> the >> AS >> and >> RS >> and >> client >> working >> together. >> Where >> OAuth >> misses >> the >> mark >> is >> the >> assumption >> that >> the >> user >> has >> to >> log >> in >> to >> the >> AS >> through >> a >> webpage >> and >> interact >> directly, >> thereby >> proving >> they’re >> the >> RO. >> It’s >> this >> latter >> space >> where >> I >> think >> we >> can >> both >> push >> innovation >> and >> also >> address >> the >> important >> and >> compelling >> use >> cases >> like >> the >> ones >> you’re >> bringing. >> >> — >> Justin >> >>> On >>> Mar >>> 22, >>> 2021, >>> at >>> 2:14 >>> PM, >>> Adrian >>> Gropper >>> <agropper@healthurl.com >>> <mailto:agropper@healthurl.com>> >>> wrote: >>> >>> I'm >>> sorry, >>> Justin. >>> As >>> a >>> Resource >>> Owner, >>> I >>> look >>> at >>> the >>> RS >>> trust >>> boundary >>> (the >>> dotted >>> line >>> in >>> the >>> diagram) >>> as >>> being >>> the >>> RS. >>> I >>> don't >>> expect >>> any >>> visibility >>> into >>> what's >>> going >>> on >>> on >>> the right. >>> >>> >>> My >>> problem >>> with >>> the >>> framing >>> you >>> propose >>> is >>> that >>> requests >>> are >>> going >>> to >>> the >>> RS >>> (or >>> the >>> AS-RS) >>> and >>> I >>> don't >>> want >>> to >>> share >>> my >>> policies >>> with >>> the >>> AS-RS. >>> I >>> want >>> to >>> keep >>> the >>> RS >>> and >>> AS-RS >>> as >>> ignorant >>> as >>> possible. >>> >>> Adrian >>> >>> On >>> Mon, >>> Mar >>> 22, >>> 2021 >>> at >>> 1:48 >>> PM >>> Justin >>> Richer >>> <jricher@mit.edu >>> <mailto:jricher@mit.edu>> >>> wrote: >>> >>> Adrian, >>> >>> >>> What >>> you’re >>> discussing >>> below, >>> in >>> terms >>> of >>> logging >>> in >>> to >>> a >>> site, >>> is >>> not >>> approaching >>> the >>> RS. >>> You >>> are >>> in >>> fact >>> approaching >>> the >>> client, >>> and >>> identifying >>> both >>> the >>> AS >>> and >>> RS >>> to >>> the >>> client. >>> The >>> client >>> is >>> a >>> client >>> /of >>> your >>> identity/ >>> in >>> this >>> model, >>> and >>> the >>> RS >>> is >>> part >>> of >>> the >>> identity >>> provider. >>> It’s >>> really >>> important >>> that >>> we >>> don’t >>> conflate >>> the >>> RS >>> and >>> client >>> in >>> this >>> way >>> as >>> it >>> leads >>> to >>> a >>> lot >>> of >>> confusion >>> downstream >>> and >>> a >>> lot >>> of >>> broken >>> trust >>> boundaries. >>> >>> With >>> that >>> model >>> in >>> mind, >>> approaching >>> the >>> “RS" >>> and >>> providing >>> it >>> your >>> identity >>> is >>> really >>> just >>> a >>> case >>> of >>> the >>> “federated >>> login >>> to >>> AS” >>> pattern >>> that >>> we >>> discussed >>> on >>> the >>> WG >>> call. >>> The >>> user >>> here >>> approaches >>> an >>> RS, >>> which >>> has >>> its >>> own >>> AS. >>> To >>> share >>> things >>> from >>> this >>> RS, >>> the >>> RO >>> has >>> to >>> authenticate >>> to >>> the >>> RS’s >>> AS. >>> This >>> particular >>> AS >>> allows >>> the >>> RO >>> to >>> do >>> so >>> using >>> an >>> external >>> identity >>> — >>> in >>> which >>> case, >>> the >>> AS >>> is >>> now >>> a >>> “client” >>> of >>> a >>> separate, >>> disconnected >>> (but >>> layered) >>> delegation. >>> The >>> ultimate >>> client >>> that >>> eventually >>> calls >>> the >>> RS >>> down >>> the >>> way >>> may >>> or >>> may >>> not >>> know >>> about >>> these >>> layers. >>> >>> >>> <PastedGraphic-1.png> >>> This >>> same >>> AS, >>> which >>> is >>> closely >>> tied >>> to >>> the >>> RS >>> and >>> trusted >>> by >>> the >>> RS, >>> might >>> also >>> take >>> in >>> FIDO >>> credentials, >>> or >>> DIDs, >>> or >>> any >>> number >>> of >>> other >>> proof >>> mechanisms. >>> The >>> output >>> of >>> this >>> is >>> an >>> access >>> token >>> the >>> RS >>> trusts, >>> but >>> the >>> input >>> is >>> up >>> to >>> the >>> AS. >>> The >>> RS >>> is >>> not >>> what >>> you’re >>> logging >>> in >>> to. >>> >>> — >>> Justin >>> >>>> On >>>> Mar >>>> 22, >>>> 2021, >>>> at >>>> 1:28 >>>> PM, >>>> Adrian >>>> Gropper >>>> <agropper@healthurl.com >>>> <mailto:agropper@healthurl.com>> >>>> wrote: >>>> >>>> I >>>> too >>>> am >>>> in >>>> favor >>>> of >>>> avoiding >>>> consolidation >>>> and >>>> correlation. >>>> Right >>>> now, >>>> when >>>> I >>>> approach >>>> a >>>> service >>>> provider >>>> (RS) >>>> for >>>> the >>>> first >>>> time, >>>> I'm >>>> offered >>>> the >>>> opportunity >>>> to >>>> identify >>>> my >>>> persona >>>> as: >>>> email, >>>> sign-in >>>> with >>>> Google, >>>> Facebook, >>>> or >>>> Apple. >>>> I >>>> know >>>> there >>>> are >>>> people >>>> who >>>> try >>>> to >>>> create >>>> one-off >>>> email >>>> addresses >>>> but >>>> that >>>> is >>>> mostly >>>> a >>>> waste >>>> of >>>> time. >>>> >>>> >>>> So, >>>> along >>>> come >>>> FIDO2 >>>> and >>>> DID >>>> wallets >>>> to >>>> the >>>> rescue. >>>> Now, >>>> in >>>> theory, >>>> I >>>> have >>>> a >>>> way >>>> to >>>> start >>>> out >>>> my >>>> RS >>>> relationship >>>> pseudonymously. >>>> >>>> >>>> When >>>> I >>>> want >>>> my >>>> resource >>>> to >>>> be >>>> discovered >>>> or >>>> shared >>>> I >>>> will >>>> post >>>> that >>>> RS >>>> URL >>>> including >>>> my >>>> pseudonym. >>>> If >>>> I >>>> then >>>> want >>>> to >>>> introduce >>>> a >>>> mediator in >>>> front >>>> of >>>> my >>>> AS >>>> or >>>> messaging >>>> service endpoint, >>>> I >>>> have >>>> that >>>> option. >>>> If >>>> I >>>> want >>>> to >>>> keep >>>> requests >>>> away >>>> from >>>> the >>>> mediator, >>>> I >>>> would >>>> publish >>>> an >>>> encryption >>>> key >>>> along >>>> with >>>> my >>>> pseudonym. >>>> >>>> - >>>> Adrian >>>> >>>> >>>> >>>> On >>>> Mon, >>>> Mar >>>> 22, >>>> 2021 >>>> at >>>> 9:55 >>>> AM >>>> Justin >>>> Richer >>>> <jricher@mit.edu >>>> <mailto:jricher@mit.edu>> >>>> wrote: >>>> >>>> On >>>> Mar >>>> 21, >>>> 2021, >>>> at >>>> 1:18 >>>> PM, >>>> Benjamin >>>> Kaduk >>>> <kaduk@mit.edu >>>> <mailto:kaduk@mit.edu>> >>>> wrote: >>>> > >>>> >>>> > >>>> On >>>> Sat, >>>> Mar >>>> 20, >>>> 2021 >>>> at >>>> 01:07:42AM >>>> -0400, >>>> Adrian >>>> Gropper >>>> wrote: >>>> >> >>>> @Alan >>>> Karp >>>> <alanhkarp@gmail.com >>>> <mailto:alanhkarp@gmail.com>> >>>> shared >>>> a >>>> talk >>>> about >>>> the >>>> Principle >>>> Of >>>> Least >>>> >> >>>> Authority >>>> (POLA) >>>> in >>>> a >>>> recent >>>> comment >>>> >> >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693 >>>> <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693> >>>> >> >>>> I >>>> recommend >>>> it. >>>> >> >>>> >>>> >> >>>> We >>>> might >>>> expect >>>> a >>>> protocol >>>> with >>>> authorization >>>> in >>>> the >>>> title >>>> to >>>> use >>>> authority >>>> >> >>>> as >>>> a >>>> core >>>> principle. >>>> I >>>> advocate >>>> for >>>> a >>>> GNAP >>>> design >>>> that >>>> maximizes >>>> the >>>> power >>>> >> >>>> of >>>> the >>>> RO, >>>> to >>>> be >>>> seen >>>> as >>>> a >>>> human >>>> rights >>>> issue >>>> when >>>> the >>>> RO >>>> is >>>> a >>>> human. >>>> This >>>> >> >>>> causes >>>> me >>>> to >>>> ask >>>> how >>>> to >>>> combine >>>> better >>>> security >>>> with >>>> better >>>> human >>>> rights >>>> in >>>> >> >>>> GNAP. >>>> >> >>>> >>>> >> >>>> Who >>>> should >>>> have >>>> the >>>> least >>>> authority >>>> in >>>> the >>>> GNAP >>>> design? >>>> >> >>>> >>>> >> >>>> The >>>> AS >>>> derives >>>> authority >>>> as >>>> a >>>> delegate >>>> of >>>> the >>>> RO. >>>> If >>>> we >>>> ask >>>> the >>>> RO >>>> to >>>> >> >>>> partition >>>> limited >>>> authority >>>> across >>>> dozens >>>> of >>>> different >>>> ASs >>>> by >>>> domain >>>> and >>>> >> >>>> function, >>>> then >>>> we >>>> are >>>> not >>>> using >>>> technology >>>> to >>>> empower >>>> the >>>> individual. >>>> >> >>>> Probably >>>> the >>>> opposite, >>>> as >>>> we >>>> introduce >>>> consent >>>> fatigue >>>> and >>>> burden >>>> normal >>>> >> >>>> people >>>> to >>>> partition >>>> their >>>> lives >>>> into >>>> non-overlapping >>>> domains. >>>> >> >>>> >>>> >> >>>> My >>>> experience >>>> says >>>> we >>>> should >>>> aim >>>> for >>>> one >>>> AS >>>> per >>>> persona >>>> because >>>> that >>>> maps >>>> >> >>>> into >>>> the >>>> way >>>> we >>>> manage >>>> our >>>> public >>>> and >>>> private >>>> identities. >>>> POLA >>>> would >>>> then >>>> >> >>>> teach >>>> care >>>> in >>>> keeping >>>> ASs >>>> and >>>> RSs >>>> related >>>> to >>>> work >>>> / >>>> public >>>> separate >>>> from >>>> >> >>>> ASs >>>> and >>>> RSs >>>> related >>>> to >>>> private >>>> life >>>> so >>>> that >>>> a >>>> policy >>>> vulnerability >>>> in >>>> our >>>> >> >>>> delegation >>>> to >>>> an >>>> AS >>>> would >>>> have >>>> the >>>> least >>>> likelihood >>>> of >>>> harm. >>>> > >>>> >>>> > >>>> Thinking >>>> about >>>> how >>>> least >>>> authority/least >>>> privilege >>>> would >>>> apply >>>> to >>>> GNAP >>>> > >>>> seems >>>> like >>>> a >>>> useful >>>> exercise. >>>> I >>>> do >>>> want >>>> to >>>> point >>>> out >>>> some >>>> potential >>>> > >>>> pitfalls >>>> with >>>> one-AS-per-persona >>>> that >>>> we >>>> can >>>> also >>>> be >>>> aware >>>> of. >>>> If >>>> > >>>> one-AS-per-persona >>>> becomes >>>> one-persona-per-AS >>>> as >>>> well, >>>> then >>>> the >>>> AS's >>>> > >>>> identity >>>> in >>>> effect >>>> also >>>> serves >>>> as >>>> a >>>> persona >>>> identity >>>> and >>>> there >>>> are >>>> privacy >>>> > >>>> considerations >>>> to >>>> that. >>>> If, >>>> on >>>> the >>>> other >>>> hand, >>>> the >>>> > >>>> multiple-personas-per-AS >>>> (presumably >>>> corresponding >>>> to >>>> multiple >>>> humans) >>>> > >>>> route >>>> is >>>> taken, >>>> we >>>> should >>>> consider >>>> whether >>>> that >>>> would >>>> lead >>>> to >>>> various >>>> > >>>> (e.g., >>>> market) >>>> forces >>>> driving >>>> consolidation >>>> to >>>> just >>>> a >>>> handful >>>> of >>>> > >>>> super-popular >>>> AS >>>> services. >>>> That >>>> topic >>>> is >>>> a >>>> current >>>> matter >>>> of >>>> concern >>>> to >>>> > >>>> some >>>> IETF >>>> participants. >>>> > >>>> >>>> >>>> Hi >>>> Ben, >>>> big >>>> +1 >>>> to >>>> this. >>>> This >>>> is >>>> something >>>> that >>>> we >>>> discussed >>>> ages >>>> ago >>>> in >>>> the >>>> UMA >>>> working >>>> group, >>>> and >>>> it’s >>>> one >>>> of >>>> the >>>> biggest >>>> problems >>>> with >>>> the >>>> personal >>>> AS >>>> (and >>>> personal >>>> data >>>> store) >>>> model. >>>> This >>>> kind >>>> of >>>> thing >>>> makes >>>> RS-first >>>> trust >>>> models >>>> really >>>> difficult >>>> in >>>> practice. >>>> >>>> As >>>> a >>>> strawman, >>>> let’s >>>> say >>>> that >>>> I’ve >>>> got >>>> software >>>> that >>>> wants >>>> to >>>> access >>>> my >>>> medical >>>> information. >>>> It >>>> calls >>>> an >>>> RS >>>> and >>>> requests >>>> access, >>>> but >>>> it >>>> hasn’t >>>> been >>>> granted >>>> anything >>>> yet. >>>> Now >>>> I >>>> as >>>> the >>>> RO >>>> have >>>> set >>>> up >>>> the >>>> RS >>>> so >>>> that >>>> it >>>> talks >>>> to >>>> my >>>> personal >>>> AS, >>>> that >>>> only >>>> I >>>> use. >>>> In >>>> addition >>>> to >>>> the >>>> RS >>>> having >>>> to >>>> be >>>> able >>>> to >>>> figure >>>> out >>>> which >>>> medical >>>> records >>>> are >>>> being >>>> requested >>>> from >>>> the >>>> context >>>> of >>>> the >>>> unauthenticated >>>> request >>>> (which >>>> means >>>> it >>>> needs >>>> identifiers >>>> in >>>> the >>>> URL >>>> or >>>> something >>>> similar >>>> for >>>> the >>>> RS >>>> to >>>> be >>>> able >>>> to >>>> tell, >>>> assuming >>>> that >>>> it >>>> protects >>>> data >>>> for >>>> more >>>> than >>>> one >>>> person). >>>> So >>>> this >>>> client >>>> software >>>> doesn’t >>>> know >>>> who >>>> I >>>> am >>>> and >>>> doesn’t >>>> know >>>> my >>>> medical >>>> record >>>> information, >>>> makes >>>> a >>>> completely >>>> unauthorized >>>> request >>>> to >>>> the >>>> RS, >>>> and >>>> the >>>> RS >>>> says >>>> “Go >>>> to >>>> Justin’s >>>> personal >>>> AS >>>> to >>>> get >>>> a >>>> token”. >>>> The >>>> client >>>> can >>>> now >>>> make >>>> a >>>> direct >>>> correlation >>>> between >>>> the >>>> data >>>> that’s >>>> being >>>> protected >>>> at >>>> the >>>> RS >>>> and >>>> the >>>> person >>>> running >>>> the >>>> AS >>>> that >>>> protects >>>> it. >>>> Importantly, >>>> this >>>> client >>>> makes >>>> this >>>> call >>>> with >>>> no >>>> prior >>>> relationship >>>> to >>>> the >>>> RS >>>> and >>>> no >>>> really >>>> auditable >>>> way >>>> to >>>> track >>>> it >>>> down >>>> after >>>> the >>>> fact. >>>> This >>>> is >>>> a >>>> design >>>> feature >>>> in >>>> the >>>> good >>>> case, >>>> and >>>> terrifying >>>> in >>>> the >>>> bad >>>> case. >>>> >>>> If >>>> the >>>> RS >>>> instead >>>> says >>>> “welcome >>>> to >>>> Medicine >>>> Doctor >>>> RS, >>>> please >>>> talk >>>> to >>>> the >>>> Medicine >>>> Doctor >>>> AS >>>> to >>>> get >>>> access”, >>>> we >>>> haven’t >>>> exposed >>>> anything >>>> at >>>> all. >>>> And >>>> from >>>> the >>>> perspective >>>> of >>>> both >>>> the >>>> patient >>>> and >>>> the >>>> RS, >>>> this >>>> is >>>> more >>>> privacy-preserving, >>>> and >>>> it’s >>>> really >>>> the >>>> least >>>> surprising >>>> option. >>>> Once >>>> the >>>> client >>>> gets >>>> to >>>> the >>>> AS, >>>> it >>>> can >>>> start >>>> a >>>> negotiation >>>> of >>>> figuring >>>> out >>>> who >>>> the >>>> RO >>>> is >>>> for >>>> the >>>> information >>>> being >>>> accessed. >>>> >>>> On >>>> top >>>> of >>>> this, >>>> the >>>> usability >>>> expectations >>>> of >>>> people >>>> managing >>>> their >>>> own >>>> AS, >>>> or >>>> set >>>> of >>>> AS’s >>>> for >>>> multiple >>>> personas >>>> to >>>> keep >>>> things >>>> separate, >>>> is >>>> a >>>> huge >>>> burden. >>>> Even >>>> in >>>> the >>>> tech >>>> community, >>>> I >>>> know >>>> people >>>> who >>>> can’t >>>> reliably >>>> manage >>>> more >>>> than >>>> one >>>> email >>>> address >>>> for >>>> different >>>> purposes. >>>> I >>>> wouldn’t >>>> expect >>>> my >>>> partner >>>> to >>>> do >>>> that >>>> — >>>> they >>>> have >>>> trouble >>>> enough >>>> balancing >>>> all >>>> the >>>> logins >>>> and >>>> sessions >>>> required >>>> for >>>> different >>>> kids >>>> remote >>>> schooling, >>>> I >>>> couldn’t >>>> imagine >>>> them >>>> having >>>> to >>>> understand >>>> all >>>> the >>>> requirements >>>> for >>>> managing >>>> multiple >>>> authorization >>>> servers >>>> and >>>> associated >>>> policies. >>>> I >>>> also >>>> don’t >>>> expect >>>> any >>>> person >>>> to >>>> “manage >>>> keys” >>>> — >>>> I’ve >>>> been >>>> on >>>> the >>>> internet >>>> for >>>> decades >>>> and >>>> I >>>> can >>>> barely >>>> keep >>>> tabs >>>> on >>>> my >>>> GPG >>>> keys, >>>> and >>>> only >>>> use >>>> them >>>> when >>>> I >>>> am >>>> forced >>>> to. >>>> This >>>> is >>>> exactly >>>> the >>>> kind >>>> of >>>> “market >>>> pressure” >>>> that >>>> I >>>> think >>>> Ben >>>> mentions >>>> above, >>>> people >>>> will >>>> just >>>> want >>>> to >>>> outsource >>>> that >>>> to >>>> someone >>>> else, >>>> and >>>> the >>>> reality >>>> will >>>> be >>>> a >>>> few >>>> popular >>>> providers. >>>> >>>> In >>>> which >>>> case, >>>> we >>>> could >>>> end >>>> up >>>> doing >>>> a >>>> ton >>>> of >>>> work >>>> to >>>> allow >>>> an >>>> RS >>>> choice >>>> only >>>> to >>>> end >>>> up >>>> with >>>> a >>>> world >>>> where >>>> the >>>> RS >>>> ends >>>> up >>>> making >>>> a >>>> limited >>>> choice >>>> anyway. >>>> We >>>> see >>>> how >>>> that >>>> plays >>>> out >>>> with >>>> OpenID >>>> Connect >>>> — >>>> RP’s >>>> could >>>> allow >>>> arbitrary >>>> IdPs >>>> but >>>> they >>>> choose >>>> Google >>>> because >>>> it >>>> works >>>> and >>>> that’s >>>> where >>>> the >>>> users >>>> are. >>>> (And >>>> that’s >>>> not >>>> to >>>> say >>>> anything >>>> of >>>> the >>>> proprietary >>>> OIDC-like >>>> protocols, >>>> but >>>> that’s >>>> another >>>> discussion). >>>> >>>> For >>>> further >>>> reading >>>> on >>>> these >>>> topics, >>>> I >>>> recommend >>>> both >>>> “Why >>>> Johnny >>>> Can’t >>>> Encrypt” >>>> and >>>> “Why >>>> CSCW >>>> Systems >>>> Fail”. >>>> >>>> So >>>> what >>>> does >>>> this >>>> have >>>> to >>>> do >>>> with >>>> GNAP? >>>> I >>>> think >>>> we >>>> can >>>> be >>>> clear-eyed >>>> on >>>> what >>>> kinds >>>> of >>>> expectations >>>> we >>>> have >>>> for >>>> the >>>> participants. >>>> If >>>> we >>>> expect >>>> users >>>> (RO’s) >>>> to >>>> have >>>> to >>>> set >>>> up >>>> the >>>> AS-RS >>>> relationship, >>>> or >>>> expect >>>> them >>>> to >>>> carry >>>> their >>>> AS, >>>> or >>>> manage >>>> their >>>> personal >>>> keys >>>> — >>>> I >>>> think >>>> we’ve >>>> lost >>>> the >>>> battle >>>> for >>>> relevance. >>>> >>>> — >>>> Justin >>>> >>> >> >> -- >> >> TXAuth >> mailing >> list >> TXAuth@ietf.org >> <mailto:TXAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/txauth >> <https://www.ietf.org/mailman/listinfo/txauth> >> >> -- >> TXAuth >> mailing list >> TXAuth@ietf.org >> <mailto:TXAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/txauth >> <https://www.ietf.org/mailman/listinfo/txauth> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> <mailto:TXAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/txauth >> <https://www.ietf.org/mailman/listinfo/txauth> >> > >
- [GNAP] Will GNAP support Zero Trust Architecture? Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Benjamin Kaduk
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Denis
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Denis
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Denis
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- [GNAP] Relationship between Authentication and Au… Denis
- Re: [GNAP] Relationship between Authentication an… Justin Richer
- Re: [GNAP] Relationship between Authentication an… Denis
- Re: [GNAP] Relationship between Authentication an… Justin Richer
- Re: [GNAP] Relationship between Authentication an… Denis
- Re: [GNAP] Relationship between Authentication an… Adrian Gropper
- Re: [GNAP] Relationship between Authentication an… Denis
- Re: [GNAP] Relationship between Authentication an… Adrian Gropper
- [GNAP] Alice a J&J COVID vaccine Denis
- Re: [GNAP] Alice a J&J COVID vaccine Adrian Gropper