Re: [GNAP] Will GNAP support Zero Trust Architecture?
Fabien Imbault <fabien.imbault@gmail.com> Thu, 25 March 2021 07:24 UTC
Return-Path: <fabien.imbault@gmail.com>
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 C5CD93A1395 for <txauth@ietfa.amsl.com>; Thu, 25 Mar 2021 00:24:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 W-TxBlC6V7Ux for <txauth@ietfa.amsl.com>; Thu, 25 Mar 2021 00:24:23 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E57A3A1393 for <txauth@ietf.org>; Thu, 25 Mar 2021 00:24:23 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id e8so937528iok.5 for <txauth@ietf.org>; Thu, 25 Mar 2021 00:24:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lUtxWIt06dK6iiIqc2upGoh79zy9IG3WNGAuVVMop8Q=; b=mRuZm0uvSfoLA2M0ZreBlI+IjnRw5oA+xtLl3sN5wMsUFoM3mP7E+ZF4InRXeXDtwn t2YWOAAtJJb/YCJG54idKsuHgcjsX8hGtZ7e/2QE3CIoYgAx3yYVVWPkIuqcC7fMsppk LYh4qZKu5adBbLdSr3iPh2iY57ouvvsxB2/xGJQw0yqDXnOURyLa3zy/LgEvRWwupdCf +QV5EOJD4Ga1ny5T9VEHknwo30BsVfRXzl4pg+yuicCB9LsY/scQjWB3R4Emhi2p2C8T xPt1EsUtY+yk18HW+t4OTQosF5cF2NUu30thkj7H5xBHhAdUFd6aesW4Iwo+5ppN10LI sWKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lUtxWIt06dK6iiIqc2upGoh79zy9IG3WNGAuVVMop8Q=; b=ZczXkynaeFSP/hl4jAc8Fbr2AfptIcijT2nP3AIHfAFxuoyGyQOAIsU/hu2TTdKolT uqvpmiAiuDIk0IU1Y8T5L8XzK45INvxEghziydlFW1esvecB5TtpEMRtdG0FVuT5wiDf 6w+aZFES/B5bu+2Gu3lbIX/6KoP/r9MLS3TV2LK3trGEKAlhG12E5rd4bb/21fC+lBJ0 62a7wfZqTcsaIikgUAaSnWkL09hyXm7RD2GF3HmshsOmF6qzKe+xzomrLraHPGS7kcE+ qje12EF3Giq6kmOgKrImMIgLiTno6ctWydfL8GjBI5WBFZ6WTW/Y55eaYPDKzYSVJYId Ufiw==
X-Gm-Message-State: AOAM533c1WIRvfVvmsRkNrb5mblPb97rA5ZovUPeHy3tFkFJOPQ5ZkBN x/HZe+vXpbD2F1/e3P0hYHf2zl/ftIR4sIxlVaQwIqr108Y=
X-Google-Smtp-Source: ABdhPJzPVWNxCwYqvlnQPOaMLFjFVbVDUDQs36DFomilRLElGRxTbYYDppBPfSBQy1HTfB0JcZkXshXGqn4AeOuzzbI=
X-Received: by 2002:a05:6602:3314:: with SMTP id b20mr5461772ioz.78.1616657062202; Thu, 25 Mar 2021 00:24:22 -0700 (PDT)
MIME-Version: 1.0
References: <CANYRo8jBZFVWyvAgVSWSmnuC+i1NaEkJEGWextzGB0xNFnD9fA@mail.gmail.com> <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <CANYRo8gMQYJXcb0FU2VCVcdbBLsopZ5Wfyo3hd1Pd5tmOSs0SA@mail.gmail.com> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <CANYRo8iPeeM3rLP9BYid2B71NzU7fR6J9Ra4=PSODTFE7i75Zg@mail.gmail.com> <CEECEE23-24D0-4C0C-B39E-9FDFF9E1E13D@mit.edu> <CANpA1Z2S8Y3+U+jOa-ZbTzsZ9hkybCnGfzx0kP8VF=Z=Se4uew@mail.gmail.com> <CAM8feuTaYEZY8BNtp5j8dAxZjBLnM-0CZQUO9UgGAAx=-qQyJA@mail.gmail.com> <CANpA1Z2Zt0ksRZqu7f6kGc5CXvWjRvuBMyDn4-EeiVE7Ndj3yw@mail.gmail.com> <CAM8feuRk6bB6ry1dy9W-9OKSgckYqicVtQ7jsrxseA2iJQdPKQ@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>
In-Reply-To: <CANYRo8iJfpF2nt4se3KNhe14B5c_+ndmwjFFAhw7ybnJa_Cq2A@mail.gmail.com>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Thu, 25 Mar 2021 08:24:08 +0100
Message-ID: <CAM8feuS0YOWC-wpz=0GP1x-7EV6fdx0puimkS6AXJP=ZtYM8aA@mail.gmail.com>
To: Adrian Gropper <agropper@healthurl.com>
Cc: Alan Karp <alanhkarp@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>, GNAP Mailing List <txauth@ietf.org>, Justin Richer <jricher@mit.edu>, Mark Miller <erights@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000ea921505be574da9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/J-8dRduccUIvfYwyRlTx3LpiqFk>
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 07:24:29 -0000
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> 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> > 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> >> 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> 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> 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> >>>>> 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> >>>>>> wrote: >>>>>> >>>>>>> Adrian Gropper <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> 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 >>>>>>>> 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> 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> 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> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Alan and Adrian, >>>>>>>>>>> >>>>>>>>>>> I've created issue AS-RO policy delegation ( >>>>>>>>>>> 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> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Fabien Imbault <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> 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> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Justin Richer <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> 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> 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> 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> 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> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >> @Alan Karp <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 >>>>>>>>>>>>>>>>> >> 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 >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>> TXAuth mailing list >>>>>>>>> TXAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>> >>>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> 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