Re: [GNAP] Will GNAP support Zero Trust Architecture?
Fabien Imbault <fabien.imbault@gmail.com> Thu, 25 March 2021 10:41 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 D747C3A1D27 for <txauth@ietfa.amsl.com>; Thu, 25 Mar 2021 03:41:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 nv0wjivRUSRN for <txauth@ietfa.amsl.com>; Thu, 25 Mar 2021 03:41:05 -0700 (PDT)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 B28AA3A1D26 for <txauth@ietf.org>; Thu, 25 Mar 2021 03:41:05 -0700 (PDT)
Received: by mail-io1-xd2e.google.com with SMTP id e8so1416515iok.5 for <txauth@ietf.org>; Thu, 25 Mar 2021 03:41:05 -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=sUESc7pL8ZXU1j3ysHyfSxtcksFrvT0Y8KEdo5TF6ek=; b=OisIJC60W31OtP+z3pfZFmZ/f9G3Be0MbWL0tHpEXDwBsbZ+xJnftxPmV64RlrXtEH S6I3E7/K43lm79jXxtGhm2YfXpIGGaRGXWFUy0Zmd/AcG3beUih+XkokJSdunS8ZSZe6 +bh2UTg0KYS+gOzw5GzcNVqvGXgtplo0olwMMauMb/TXUaQ2dntp5FsxOiaLDR1UHC2y USx2Dt9k0u9S113oK9Zg5XP9xbklvlAZwZbydM7q+RYI/0L/jMwGsu0tuD/KFwjQ5AQt faJ/XdAkHKcotTywJTTeMuAkgX0Sdol9ervTfjt1B+s/BowweAlgKdKDaNMdndqKYkdB PmXQ==
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=sUESc7pL8ZXU1j3ysHyfSxtcksFrvT0Y8KEdo5TF6ek=; b=qF5/34DaW165OH2NK67gLPj2i88TkSVP57bz22bVx+Bc86OTTAHvVmaSELHd7FE8F2 ly3rwtS/K7Bma+5cBL7vKvgbuQW9NpgYW4iuj0TUSA8StpmAElCsqKbY8KoTvFLouBd/ ELeRfxZRNMfwoeymOzz3bX+KJyNyy7FqP2K41xxafTo6gk+Uh38rIyB9RXBgzJdwgYvD alD3BlELvyj8f3sYKxK19+dwlituVxb8Y+jXGNqAxSwOdMu4KYq8xo/qwleIYyJYGrcn kRv1AtVp72PdCq2Cz1hdoOY+Oal7tSwvzvSWNj/uXXzy+EqApDEHd7D8CqKQv4TiRWaG sEZg==
X-Gm-Message-State: AOAM533VRQkZYvFeYhdTziQIEyis5uNWwDITZhJ9CmTqLiMqhaPQClSv ENFxOIP5q8ePXe0BWPtEhNOYVEvL0T9ZsxaKmJI=
X-Google-Smtp-Source: ABdhPJx7ktIXPCezmdwwfVEjNImhG9XP4Etns5+Ima+GS8ChQ5I6661wHOnUwdr0Cn5xJb6I8ayi+tI5F/RG3FEP8cI=
X-Received: by 2002:a02:c6b4:: with SMTP id o20mr6929655jan.124.1616668863777; Thu, 25 Mar 2021 03:41:03 -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> <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>
In-Reply-To: <CAM8feuTJawB+msiSrYUeen15eHLDcOzD4diy6++DNoYYcHqMug@mail.gmail.com>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Thu, 25 Mar 2021 11:40:52 +0100
Message-ID: <CAM8feuTqMXF4b+ZaEJpkfeTJeBsuf227VNC3p1sDGJByFUn8jA@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="00000000000058511305be5a0dee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/_pV9IkaJb8MGxkOGBCK2SPWvv7g>
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 10:41:11 -0000
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> 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> > 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> >> 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> >>> 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> 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> >>>>> 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