Re: [GNAP] Will GNAP support Zero Trust Architecture?
Adrian Gropper <agropper@healthurl.com> Fri, 26 March 2021 15:26 UTC
Return-Path: <agropper@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 08BF23A2124 for <txauth@ietfa.amsl.com>; Fri, 26 Mar 2021 08:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 TFQQYMz50TpA for <txauth@ietfa.amsl.com>; Fri, 26 Mar 2021 08:26:14 -0700 (PDT)
Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) (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 DFD373A2121 for <txauth@ietf.org>; Fri, 26 Mar 2021 08:26:13 -0700 (PDT)
Received: by mail-ua1-f43.google.com with SMTP id y20so1520282uay.6 for <txauth@ietf.org>; Fri, 26 Mar 2021 08:26:13 -0700 (PDT)
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=VYx1GtEDW61XUp1SCnP5Gw1KgbT5YVEOD35BEEcAfDo=; b=jQCbKoIUrojhN6xtZaOEhEvCG6NwUvT/T7kI1pIFBJpYoG2o4zjcxkaDV8WWPV82cY oRSCwAU7vvmKjIYwPtG7mbaJxIMKVR2nA6r4uIHRb84V4zV6tnwukM0Q1iKaQytxrmYO 1vwgZnQqZY9KGtZw+oy8HTCh2uXGwQLJvcp5k78o4apjyLQHTN8uhni3LMvZJnsstQdV kDqyegC1WPxP+t3zuX7mgC7k+ZP9itkVnjd8pQQT1C3Ez3zz2dTpyLwsOqLvEm+O32qF 7JS7TiwKvcJdgjLbgaqBdGjUBGUFX02n6uQoLOVu71+fdzlIFD/HeSvCZ9YwCBgkgWJi TAnw==
X-Gm-Message-State: AOAM533P0Pn/FzTp1bSsCvob6RaEkgvY8KXpZVkljBBZofYwdW4jy+Ou WqhRRChzdJ47uJSLlSjhLubqFxiVKbvxtytXgZBTG2dcR5Y=
X-Google-Smtp-Source: ABdhPJzTTx7GBBjTwz6MfWtS8X2rAC8fGhpGvklkPVBqrm19v0V4V/CBbL85MCgICb2lPMV86YlOyONlKn85UoP0iv0=
X-Received: by 2002:ab0:30a3:: with SMTP id b3mr7942954uam.0.1616772372289; Fri, 26 Mar 2021 08:26:12 -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> <CAM8feuTqMXF4b+ZaEJpkfeTJeBsuf227VNC3p1sDGJByFUn8jA@mail.gmail.com> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <CANpA1Z3x2vZXsvtcKfvFMyrWKv0XxXVWaJ=B3eaTStmbFc+gXA@mail.gmail.com> <E1008110-FBE9-42F2-8649-6ECCF0459D7D@mit.edu> <CANpA1Z2kRZPLPY6qgAJ6KjxbwGTR6B4ZUq=JGsR-6g_STBrqNg@mail.gmail.com> <CANYRo8gXtwAi8f6iHmNfgoY7E1ism+mWJYJriccugHfus+EDmg@mail.gmail.com> <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> <CANYRo8iG0KKe39Ws2avP59BNn0yJtGt3y6jQ8_zr5rmkNUbt-g@mail.gmail.com> <FFE20253-6086-43D2-84D4-C8E1BC9E6613@mit.edu> <CANYRo8jXq5LtU9RhwtCpxVDTHhk6sv9Ey+oznfyRHkA3zLwwRQ@mail.gmail.com> <497B7A43-546E-4296-916F-6D177AEBE228@mit.edu>
In-Reply-To: <497B7A43-546E-4296-916F-6D177AEBE228@mit.edu>
From: Adrian Gropper <agropper@healthurl.com>
Date: Fri, 26 Mar 2021 11:26:00 -0400
Message-ID: <CANYRo8h_q1VZRGC2=-TH_9bYSAkXp5U1FGc9STqM+fYMKR6wkg@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Alan Karp <alanhkarp@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>, Fabien Imbault <fabien.imbault@gmail.com>, GNAP Mailing List <txauth@ietf.org>, Mark Miller <erights@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000eedc9e05be7226b8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/BLwWFUG-NJuykrpiNNw9PNmzW04>
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: Fri, 26 Mar 2021 15:26:22 -0000
Good. I agree with the externalizing framing you use. To me, they are a pair. They represent the separation of concerns I’m focused on. The AS has policies, gets requests from clients, and returns access tokens. So what are we disagreeing about? - Adrian On Fri, Mar 26, 2021 at 10:38 AM Justin Richer <jricher@mit.edu> wrote: > Adrian, > > Yes, the RO is the party/entity which holds the rights for delegation, and > they perform that delegation to a piece of software (the client) through > the AS. The RS is what they’re delegating the access of, for API-access use > cases (again, user/subject information is similar but different). > > There isn’t a delegation between the RS and AS, then. You can perhaps view > them as externalizing functions that they might otherwise hold close, but > not delegating in the same way the client gets delegated to. You can frame > it one of two ways: > > - The RS externalizes its security, policy, authorization, and delegation > functions to the AS and looks for access tokens from the AS as proof of > that happening (this is the most in line with the model you’ve been > presenting) > - The AS externalizes its data-API functions to into the RS and produces > access tokens for the RS to consume/validate (this is actually the model > that OAuth 2 started with, in extracting the RS as a separate entity as > opposed to OAuth 1) > > They tell different views of the same reality. In OAuth, it’s assumed that > the RO interacts with the AS directly to perform the delegation to the > client. In GNAP, we’ve got an opportunity to expand that, which has been > (to me) one of the biggest outcomes of this discussion. > > — Justin > > On Mar 26, 2021, at 10:04 AM, Adrian Gropper <agropper@healthurl.com> > wrote: > > Justin, > > Big YES to “ The conceptual framework of an AS that takes in lots of > different information and spits out access tokens is exactly the > abstraction layer that is necessary for making these use cases > interoperable.” and probably everything else you just said. > > I seem to not understand the delegation design between RS and AS. In my > view, that delegation always goes through the RO, although the RO may be > forced to choose from a list provided by the RS. > > In my view, GNAP, can acknowledge this and design to be agnostic to > whether the AS is specified by he RO or picked from a list of 1 or more > choices provided by the RS. > > - Adrian > > On Fri, Mar 26, 2021 at 9:30 AM Justin Richer <jricher@mit.edu> wrote: > >> Adrian, >> >> I disagree, I believe that what I have laid out is exactly separating the >> concerns into working components. >> >> Like OAuth before it, GNAP is a protocol negotiate access for a client >> instance to an RS, using an AS as the facilitator of that delegated >> negotiation. (Unlike OAuth, it’s importantly also for negotiating user >> information to the client directly from the AS with no RS involved, but >> that’s an aside for the purposes of our conversation here). >> >> If a particular GNAP RS also allows other kinds of processes to enable >> access to it, that is completely fine, but outside of GNAP. If an RS allows >> a username/password HTTP Basic auth in addition to accepting access tokens, >> it can do so, but GNAP doesn’t have anything to say about the Basic auth >> use, or even its relation to any access tokens or RO’s or anything else. If >> an RS accepts structured access tokens signed by trusted keys that don’t >> come from an AS through a negotiated request — again, that’s fine, but GNAP >> is silent about the RS doing that. If the RS acts as “its own AS” then it’s >> really just an RS and an AS living in the same box. Again, that’s fine, and >> super common with OAuth today. >> >> GNAP is solving the problem of connecting the client to the RS through >> means of an AS. Other solutions are possible and many of them can be >> deployed right alongside, but that’s not the corner of the world that GNAP >> is solving. GNAP should be concerned about how these other technologies can >> be used alongside it. I think there’s a lot of room for the things that >> you’re talking about, and more importantly for solving the use cases that >> you’re bringing. But GNAP should be more than a single-point solution, and >> so we need to balance these concerns. The conceptual framework of an AS >> that takes in lots of different information and spits out access tokens is >> exactly the abstraction layer that is necessary for making these use cases >> interoperable. >> >> — Justin >> >> On Mar 26, 2021, at 8:30 AM, Adrian Gropper <agropper@healthurl.com> >> wrote: >> >> @Justin, there’s no separation of concerns here. No partition between >> processor and controller. No data minimization. And, I see no obvious >> reason to make this the core of GNAP. >> >> The one thing we can probably all agree on is that there’s only one RS >> and one RO. >> >> The core of GNAP, in my opinion, can be built and explained around this >> simple design. The RS is a processor. The RO is a controller. The RS bears >> only security responsibility. The RS bears no privacy responsibility. The >> RO delegates this to the RS but this is not authorization as the A in GNAP. >> >> The RO retains all rights to delegate within the scope of things that the >> RS is willing to support using various token formats and endpoint options. >> Some of these options may do all sorts of things for all sorts of clients >> and user-agents but these are options. >> >> For example, if a request comes to the RS that is not in the form of an >> access token, then it either gets sent to the RO or their agent, or it gets >> logged and dumped. One such option, common in healthcare, is “Break the >> Glass” where the RS is acting as an authorization server because the >> user-agent is making a request instead of presenting an access token. GNAP >> can offer this as an option but it is not our core. >> >> Adrian >> >> >> >> On Fri, Mar 26, 2021 at 7:15 AM Justin Richer <jricher@mit.edu> wrote: >> >>> I have a big problem with this line: >>> >>> > the RS and AS-RS only see access tokens. The requests (from RO') that >>> resulted in an access token are none of their business. >>> >>> In the trust model we’ve been discussing, the requests that result in >>> access tokens are *solely the business of AS-RS*, since AS-RS is the >>> only entity that’s allowed, and trusted by the RS, to create access tokens >>> for the RS. That is its entire job, the entire reason it exists in the >>> system. By definition the party generating tokens for use at the RS is the >>> AS for that RS, I don’t care how you deploy it. If RO wants to give access >>> to someone else (who isn’t an “RO" anymore, they’re another end-user), then >>> that end user’s client software will need to talk to AS-RS to get its own >>> access token. >>> >>> Now here’s the trick: when the end user’s client instance talks to >>> AS-RS, that does NOT mean that AS-RS needs to know all the details and >>> policy reasons that it should give an access token to that client instance. >>> It doesn’t even need to know the existence of another end user. It doesn’t >>> need identity, it doesn’t need policy. Sure, it COULD handle all of that >>> internally, and many will, but the protocol doesn’t demand it. >>> >>> This means that the first client instance, the one that gets the access >>> token, can also be given something alongside the access token that it can >>> then hand to another piece of software (or to a person to hand eo their >>> piece of software). This artifact is not an access token. This artifact >>> could be something structured that the client understands, and can make >>> derivatives of, and present back to the AS-RS for getting new access >>> tokens. There could be multiple different flavors of this kind of artifact >>> for different kinds of environments and groups. But what they all have in >>> common is that they can potentially be used to request more access tokens >>> within some context at the AS-RS. >>> >>> — Justin >>> >>> >>> >>> On Mar 25, 2021, at 5:50 PM, Adrian Gropper <agropper@healthurl.com> >>> wrote: >>> >>> My issue is with Alan's: >>> >>> "7. Another user agent (RO') can contact any holder of the access token >>> or the service's policy agent (AS-RS) to get a delegated access token." >>> >>> >>> I would prefer "7A. Another user agent (RO') can contact any holder of >>> the access token." by default so that the AS-RS does not see the requests. >>> In other words, the RS and AS-RS only see access tokens. The requests (from >>> RO') that resulted in an access token are none of their business. >>> >>> The reality is that RO' can discover a resource RS and can share >>> whatever information with RS-AS they want and the RO may not even know >>> about it unless the RS decides to let them know somehow. This seems to be a >>> drawback of the capabilities approach. >>> >>> In terms of privacy and control, I, as the RO, want a contract with the >>> RS that says that I or my agent (AS-RO) must sign an access token. This is >>> a fundamental audit requirement. Without it, a rogue RS and AS-RS can do >>> all sorts of things and the RO would never know. I understand that a rogue >>> RS might not support an honest contemporaneous log of access tokens >>> presented so there's a trust issue here that I seems unavoidable unless I >>> specify in my RO-RS contract that they use a separate contemporaneous log >>> such as AS-RO for every access token presented and risk being sued if they >>> process an access token without also updating the separate log. >>> >>> - Adrian >>> >>> >>> On Thu, Mar 25, 2021 at 1:22 PM Alan Karp <alanhkarp@gmail.com> wrote: >>> >>>> Justin Richer <jricher@mit.edu> wrote: >>>> >>>>> Hi Alan, >>>>> >>>>> In all of my discussion, and in the spec itself, the RO is the >>>>> :entity: in charge of approving rights. They’re probably a person. It might >>>>> be software that makes a policy decision in some way, or a corporate >>>>> entity, or something like that. But it’s not assumed to be a computational >>>>> agent in the terms of the protocol itself. Would that recast what you’re >>>>> saying below? >>>>> >>>> >>>> Hmmm. I guess not. It's just that the person would be using some UI >>>> to express their decisions to what I called the user agent. That model >>>> fits in very nicely with what we did with Polaris, our virus safe computing >>>> environment for Windows XP, >>>> https://dl.acm.org/doi/10.1145/1151030.1151033. The person would >>>> click on the icon for a Word file, and an instance of Word would open with >>>> only the permission needed to edit that one file. Same thing here. The >>>> client could ask for permission to use the resource, or permission could be >>>> granted implicitly when the user selects a resource associated with a >>>> specific client. >>>> >>>> -------------- >>>> Alan Karp >>>> >>>> >>>> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer <jricher@mit.edu> wrote: >>>> >>>>> Hi Alan, >>>>> >>>>> In all of my discussion, and in the spec itself, the RO is the >>>>> :entity: in charge of approving rights. They’re probably a person. It might >>>>> be software that makes a policy decision in some way, or a corporate >>>>> entity, or something like that. But it’s not assumed to be a computational >>>>> agent in the terms of the protocol itself. Would that recast what you’re >>>>> saying below? >>>>> >>>>> — Justin >>>>> >>>>> On Mar 25, 2021, at 12:36 PM, Alan Karp <alanhkarp@gmail.com> wrote: >>>>> >>>>> There seems to be some confusion about how AS-RO comes into the >>>>> picture, probably because of the "AS" part. I'm going to try to clear up >>>>> that confusion by more carefully explaining what I mean. >>>>> >>>>> I'm assuming that RO is a computational agent representing the person >>>>> who is the resource owner, something called the "user agent" in operating >>>>> systems lingo. I'm also assuming that it's possible to do delegation, >>>>> either locally or by token exchange with AS-RS. All delegations are >>>>> potentially sub-scoped, but you may also want to delegate with full scope >>>>> to have a separately revocable access token. >>>>> >>>>> Here's an example of how things work in a capability oriented system. >>>>> >>>>> 1. Someone, the service owner, creates a service. >>>>> 2. The service owner contracts with an policy agent (AS-RS) to >>>>> create and manage access tokens for that service (RS). >>>>> 3. A person wishing to create a resource at RS uses their user >>>>> agent (RO) to contact the service owner's policy agent (AS-RS) and gets >>>>> back an access token for that resource. >>>>> 4. That user agent (RO) can >>>>> 1. use that access token to invoke the resource, or >>>>> 2. delegate an access token to a client of the user agent's >>>>> (RO) choice, or >>>>> 3. contract with a policy agent (AS-RO) to manage those >>>>> delegations on behalf of the user agent (RO), or >>>>> 4. specify a policy with the service's policy agent (AS-RS). >>>>> 5. A client can contact any holder of the access token (the user >>>>> agent (RO) or its policy agent (AS-RO)) or the service's policy agent >>>>> (AS-RS) to get a delegated access token. >>>>> 6. That client can delegate that token to another client. >>>>> 7. Another user agent (RO') can contact any holder of the access >>>>> token or the service's policy agent (AS-RS) to get a delegated access token. >>>>> 8. The other user agent (RO') can >>>>> 1. use that access token to invoke the resource, or >>>>> 2. delegate it to a client of its choice, or >>>>> 3. contract with a policy agent (AS-RO') of its choosing to >>>>> manage those delegations on its behalf, or >>>>> 4. specify a policy with the service's policy agent (AS-RS). >>>>> 9. and so on >>>>> >>>>> When any of these computational agents, user agents (ROs) or clients >>>>> acting on their behalf, invokes the resource, AS-RS verifies that the >>>>> access token is a valid delegation, i.e., proper sub-scoping, hasn't been >>>>> revoked, and that it authorizes the request being made before telling the >>>>> service (RS) to honor the request. At no point does the service's policy >>>>> agent (AS-RS) know which computational agent did any particular >>>>> delegation. (Token exchange can be done as anonymously as possible.) In >>>>> particular, the policy agents (AS-RO) need not be the same, or even >>>>> compatible with, the service's policy agent (AS-RS). GNAP specifies the >>>>> protocol between requesters, invokers, delegators (for token exchange) of >>>>> tokens and AS-RS. That protocol need not be used between user agents (RO), >>>>> clients, or other policy agents (AS-RO), but it is likely to be. >>>>> >>>>> ------------- >>>>> Alan Karp >>>>> >>>>> >>>>> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer <jricher@mit.edu> wrote: >>>>> >>>>>> The way I’m thinking about Adrian’s use case is that what we’re >>>>>> calling the “AS-RO” isn’t an “AS” in the traditional OAuth/GNAP sense, at >>>>>> least not exactly. This is the agent that the RO can use to set policies >>>>>> and manage consent on their behalf, and I’ve been arguing that it fits >>>>>> better into this vaguely-defined “interaction component” aspect of the >>>>>> current AS definition, and it’s not currently separated from the AS >>>>>> definition. The “AS-RS” maps to what we’d call the “AS” in OAuth/GNAP >>>>>> traditionally, it’s what the RS trusts to issue tokens. In traditional >>>>>> OAuth the AS-RO and AS-RS are always the same thing, from a functional >>>>>> protocol perspective. An important point here is that from a client’s >>>>>> perspective, they’re only talking to the AS-RS since that’s where the >>>>>> client gets its tokens, because at the end of the day the client just wants >>>>>> to call the API at the RS and doesn’t care how that happens (from a >>>>>> protocol standpoint). >>>>>> >>>>>> Note well: Even thought I don’t believe that “AS-RO” is an >>>>>> authorization server at all, I’m going to keep using that term below for >>>>>> consistency with previous discussion. >>>>>> >>>>>> So we have these fundamental relationships around getting the client >>>>>> to access the RS: >>>>>> >>>>>> 1. RS trusts AS-RS to issue tokens that RS will accept, validate, and >>>>>> process for requests from client >>>>>> 2. Client trusts AS-RS to issue tokens that client can use at RS >>>>>> 3. RO trusts RS to protect RO’s api through delegated access >>>>>> >>>>>> On top of that, we’ve got some additional aspects that we’re >>>>>> discussing: >>>>>> >>>>>> 4. RO trusts AS-RO to manage RO’s policies at runtime >>>>>> 5. AS-RS trusts AS-RO to assert RO’s policies for access to RS >>>>>> 6. Client trusts whatever AS-RS sends client to deal with, including >>>>>> possibly RO-AS at runtime, because of (2) >>>>>> >>>>>> What I have been saying is that 4/5/6 are optional details of how >>>>>> RS-AS runs things, and I think this also maps with Adrian’s view of choice, >>>>>> since if my RS’s AS-RS doesn’t allow me to plug in my own AS-RO then I >>>>>> would be motivated to pick a different RS who’s AS-RS lets me do just that. >>>>>> The same way I’d pick a different RS if their surrounding services didn’t >>>>>> accept my preferred federation login and I didn’t want to make another >>>>>> account. Of course, market forces being as they are, I might not have much >>>>>> of an actionable choice in RS, but GNAP can’t change that. >>>>>> >>>>>> What we can do is make it possible for AS-RS to talk to AS-RO, both >>>>>> in philosophy of the protocol design and in concrete hooks to support (6) >>>>>> above. >>>>>> >>>>>> Separately, we can approach the issue of making 1/2 above more >>>>>> dynamic. This was UMA2’s “federated authorization” approach, and is behind >>>>>> a lot of the “bring your own AS” models out there. The problem with these >>>>>> is that we know from many years of experience that most RS’s aren’t >>>>>> interested in doing anything of the sort. >>>>>> >>>>>> So with GNAP we can instead allow 4/5/6 to vary in a predictable and >>>>>> consistent way, letting the RS keep control over 1/2, thereby enabling >>>>>> choice in (3). We don’t have to be the ones who define the all of the >>>>>> details of every permutation of (5) to enable this, though. Some of this is >>>>>> going to be configuration out of band, some of it’s going to be >>>>>> communication at runtime. This is where VC’s, ZCAPs, CHAPI, DIDComm, FIDO, >>>>>> and a whole swath of other tech can come in and help out. I don’t think we >>>>>> need to put all the details for using these into core, nor do I think we’ll >>>>>> pull of The Great And Ultimate Abstraction for using these and other >>>>>> approaches. But we can at least start talking about “AS-RS” in such a way >>>>>> that it no longer assumes it’s always the same party dealing with the RO >>>>>> directly. >>>>>> >>>>>> — Justin >>>>>> >>>>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault <fabien.imbault@gmail.com> >>>>>> wrote: >>>>>> >>>>>> To reframe it closer to GNAP: >>>>>> - AS = AS-RO, that's where you find the RO policies. The AS issues >>>>>> access tokens to the client. >>>>>> - the RO policies could be a) defined locally or b) in relationship >>>>>> with the RS >>>>>> >>>>>> There have been several ideas related to the AS-RS relationship b: >>>>>> b1) the RS issues capabilities (which can be further attenuated by >>>>>> the RO) >>>>>> b2) Adrian also discussed a DID based solution >>>>>> b3) there was also an alternative ACL proposal from Denis (+ >>>>>> preflight) >>>>>> >>>>>> Fabien >>>>>> >>>>>> >>>>>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> 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 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>> -- >>>> 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