Re: [GNAP] Will GNAP support Zero Trust Architecture?
Denis <denis.ietf@free.fr> Thu, 25 March 2021 08:19 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 C2BDE3A157E for <txauth@ietfa.amsl.com>; Thu, 25 Mar 2021 01:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.72
X-Spam-Level:
X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-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 FR46dVxoPh1o for <txauth@ietfa.amsl.com>; Thu, 25 Mar 2021 01:19:27 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608A53A157A for <txauth@ietf.org>; Thu, 25 Mar 2021 01:19:24 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.53.231]) by mwinf5d29 with ME id kYKL2400X4zJUWJ03YKMUH; Thu, 25 Mar 2021 09:19:22 +0100
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 25 Mar 2021 09:19:22 +0100
X-ME-IP: 90.79.53.231
To: txauth@ietf.org
References: <CANYRo8jBZFVWyvAgVSWSmnuC+i1NaEkJEGWextzGB0xNFnD9fA@mail.gmail.com> <CANpA1Z2__Y2UiQ-x_Fz4Q05guFhi-rOygJ+pHkNjbRUdh2Y97Q@mail.gmail.com> <CAM8feuT9pG6sNDpR5SUfKzX2YsX8H6VK9jmNdJLXy_g7EnPMNQ@mail.gmail.com> <CANYRo8jnmkG-LXSKsZZyHDqO7yZH3LAVzhW2qKPCvxpPnJvYnw@mail.gmail.com> <CANpA1Z2xAdG=Hu09wWb6a0Qc7DPPA5rU24oaGb4GMZfjjQbn-Q@mail.gmail.com> <CANYRo8j8ig9gzfJmNOCk=6nOPa=nQmCQahpyuJTPGViA3wj1Cw@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>
From: Denis <denis.ietf@free.fr>
Message-ID: <650a3e87-701f-f5b0-6b9f-5c591169fea4@free.fr>
Date: Thu, 25 Mar 2021 09:19:20 +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: <CAM8feuT+noLdtUYaUGfzhezTea+Uy6+9xWfb814TOg4w0u_tOA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------6AB2240A9C01BEB7B36CFD0C"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/YCEUHJTbL3wgNeHp8Pa0t3WYev8>
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 08:19:33 -0000
I am full lost in where we stand with all these ideas which look like a Brownian motion. Which entity is trusting which other entity and for which purpose(s) ? Denis > 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