Re: [GNAP] Will GNAP support Zero Trust Architecture?

Alan Karp <alanhkarp@gmail.com> Fri, 26 March 2021 15:35 UTC

Return-Path: <alanhkarp@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 823DC3A2160 for <txauth@ietfa.amsl.com>; Fri, 26 Mar 2021 08:35:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSRpRx1WeV5s for <txauth@ietfa.amsl.com>; Fri, 26 Mar 2021 08:35:44 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 7515A3A215E for <txauth@ietf.org>; Fri, 26 Mar 2021 08:35:44 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id x14so5580905qki.10 for <txauth@ietf.org>; Fri, 26 Mar 2021 08:35:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JHR4SVK49FeLbzQF0lQh0LIBu8zdPYxwd7mQmB9Tbzc=; b=jPUtkw0h6ihg+UPPs5H6Aflh9XsrXoIBZQZt58c1lP3dYPqa8bQxO5JgEtSjyoghNp I3pUGxXBAO90w2pmdbSwcpjHO7jNCRDsmO6/sboDWsgJuqeiL+f/sOT2T5Qt9oXvP6YD 0pQm8G6MZ3kBdQiR/P/DwQuQANVkBJ6yPpxY51lUChX8HT03eIuJexlRicjyaockKYN1 Mgo6ABJH2jyBbUm05dzU0PbVLrtU/KRqiGiIG0W4Y+AdBWCctvlOYiaTAEzpXIUTNJop Mxyh2j1m5RjQO+NZsb8gbKn5RW+vzt085jRlt8CXJwmjNDSAwO16YkafwC/p/EZT1lIV 5aUQ==
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=JHR4SVK49FeLbzQF0lQh0LIBu8zdPYxwd7mQmB9Tbzc=; b=qtuBxudRrfuv6aBM75e6/fvptCcx1eYQ7EwfAj2UpOG5YqTcvbrUPRVytr7a/HxE+h fRQSSLnXzmAA4j9wSJK2xdokTDi+w8shdXBvkUAkMVfYepqzCUaqP7NfqdSX5kO20CpI p2MKt/2rzS4G7V8HyCXXEzbHJd+HgshdB0zG+sdrx3b7j3bYJcntaSMjZmamKPfJvtkR KZnULFf97HYn6KHkHPaaSIHNKZdO1WGYp25uEHzyfyvcdsPUoZGeLf7fBj5cCmVF5YlU L7KWmJDCTvJiW6vVHlvxov95naZzUvhi+pLHcL0ni5299IN8vhCyFxOtxLR45A45t6VP P+9w==
X-Gm-Message-State: AOAM5331bivp54tf0wGR7mud96nb5hy2fs5uQFW9daV7ie2DqsT1oy1i PWY/iaBgPqxdOn6MJ6k4PzGU4bf0RleqtR9R71E=
X-Google-Smtp-Source: ABdhPJyI2zM+4TY9IPp14lxdQKKngY6ha3suDWfEFNUYauSUSG/5EWtivjSdCrVghzHLGqKr7gpsWA96Cay+tVngFEk=
X-Received: by 2002:a05:620a:2206:: with SMTP id m6mr13531377qkh.176.1616772941789; Fri, 26 Mar 2021 08:35:41 -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> <CANYRo8h_q1VZRGC2=-TH_9bYSAkXp5U1FGc9STqM+fYMKR6wkg@mail.gmail.com>
In-Reply-To: <CANYRo8h_q1VZRGC2=-TH_9bYSAkXp5U1FGc9STqM+fYMKR6wkg@mail.gmail.com>
From: Alan Karp <alanhkarp@gmail.com>
Date: Fri, 26 Mar 2021 08:35:29 -0700
Message-ID: <CANpA1Z1pNLaTcK9sYnG4Yx6ovJ5Z8kSAqnkN07mrG_hMNXtRGg@mail.gmail.com>
To: Adrian Gropper <agropper@healthurl.com>
Cc: Justin Richer <jricher@mit.edu>, 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="000000000000e0bc4605be724872"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/hPBHrxq2N5ddWcAgzPioNehGYsk>
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:35:53 -0000

 Adrian Gropper <agropper@healthurl.com> wrote:

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

I thought you also want RO to be able to delegate to a client without AS-RS
knowing what policy was used for that delegation.  That's the function of
AS-RO.  The client asks AS-RO for some permissions.  AS-RO either does a
token exchange with AS-RS or gives the client something to present to AS-RS
to get a new access token.  Introducing AS-RO also allows RO to express
policies that AS-RS may not support, such as break glass.

--------------
Alan Karp


On Fri, Mar 26, 2021 at 8:26 AM Adrian Gropper <agropper@healthurl.com>
wrote:

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