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
>>>>
>>>
>>>
>>
>