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