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

Adrian Gropper <agropper@healthurl.com> Thu, 25 March 2021 07:04 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 ACCE33A1308 for <txauth@ietfa.amsl.com>; Thu, 25 Mar 2021 00:04:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 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_DNSWL_BLOCKED=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 34Vok2c1hc0t for <txauth@ietfa.amsl.com>; Thu, 25 Mar 2021 00:04:41 -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 A5DA23A130F for <txauth@ietf.org>; Thu, 25 Mar 2021 00:04:41 -0700 (PDT)
Received: by mail-ua1-f43.google.com with SMTP id v23so208199uaq.13 for <txauth@ietf.org>; Thu, 25 Mar 2021 00:04:41 -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=xrxAzAqRt1fInSSEpnER+Mb3FlJ71aMhZbpd/+AjZ4s=; b=O5ZbA7H85oicHdSQpGgMdYEjVfMK928dEI3PZ52Yq0DRa0YOoCaokp9NLn0sr9kWFD MMLMMUIR69DU+mf+N4qtziqN6x2qg3EosH+jMUwLGsmBqzaYMVwMg0YE661TolBd5QFv vkLAPvGCul6Jc96U6bOM0PdBeS5zd9HoLiAjDav/J3r6IFQhQ335riGs9+oMQ/catIhF SzKfIJTpQEImnseyddu02OpsrRPkNjgxr4Cuj6fHf2Tm5RgFZ6UM09a47x0v8j66B7Rn QuVqfqXTn6/73U2tdXkF8X4OMBiqoQdRr8OEnJ0X26auBHtoppe+58ZxWhCzUCniNllC +Iqw==
X-Gm-Message-State: AOAM533UtQ+AQ1N4wlVaBvA8ROjLuAilIdRubcur1ptLlu+In5ma6UbM S6qaOWd6yDOVDI3FTE0UIeppqtJdut1JK2lNhQY=
X-Google-Smtp-Source: ABdhPJxBC2R3lFKbJN+zM5blk5niMQCZ7XBADm+K1rkjkIlkayuX+s5VP7kfpUkuK5QhaRzNB+5v9he9UobIV798DiU=
X-Received: by 2002:ab0:7115:: with SMTP id x21mr3767589uan.39.1616655880018; Thu, 25 Mar 2021 00:04:40 -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>
In-Reply-To: <CAM8feuSGR58Y1a0ta5EQThwDeRJfXNLehYe_zhBqvhu+8tDzPg@mail.gmail.com>
From: Adrian Gropper <agropper@healthurl.com>
Date: Thu, 25 Mar 2021 03:04:28 -0400
Message-ID: <CANYRo8gbTuDYHDHaR=y4cWOimYWqptEOYD6UbsbCpdd0Rh6QHQ@mail.gmail.com>
To: Fabien Imbault <fabien.imbault@gmail.com>
Cc: Alan Karp <alanhkarp@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>, GNAP Mailing List <txauth@ietf.org>, Justin Richer <jricher@mit.edu>, Mark Miller <erights@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000073de3605be570771"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/jCkRERsICRVjQyJlrkY71n-Tfo4>
Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture?
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Mar 2021 07:04:47 -0000

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