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

Adrian Gropper <agropper@healthurl.com> Thu, 25 March 2021 07:16 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 0661A3A136F for <txauth@ietfa.amsl.com>; Thu, 25 Mar 2021 00:16:54 -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_DNSWL_NONE=-0.0001, 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 Dnzl1VsqhAIQ for <txauth@ietfa.amsl.com>; Thu, 25 Mar 2021 00:16:49 -0700 (PDT)
Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com [209.85.221.169]) (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 23DC73A136E for <txauth@ietf.org>; Thu, 25 Mar 2021 00:16:49 -0700 (PDT)
Received: by mail-vk1-f169.google.com with SMTP id k27so183911vki.2 for <txauth@ietf.org>; Thu, 25 Mar 2021 00:16:49 -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=LZEkL5gQ3UISMppn4BPUYMZcHtRHkApQf6CkOn7ugl4=; b=Cv5LCTl5hEucXUqE2YEaWm5iWX4ZDG3RTdxHm6BRmAsJMbg745c0OYJIpiDbpNzRSU OKIkTnuGZRFxg9l3Q1RerDDGXCmUbGjD/Uj5zOa0b3GFd57JPlBLIrWo3a9jI6WOK8P2 fHn3NHPIvSPFz1C5yQcIYRxS/oZodae+Ps80Po1od+mvYrF4DGTxu+8uUGPzuGGj69R5 T/+BNflNpL7uZo6iflp0uiiRavzjt327Ulshkq8/WNwQtWl5V3kunEvpJlRTLkEMD2jB KoqYMStNM8eJFfNelH5rJoPQY76/reR2S5PoakN5Ust6VvxoEOkL4pWstYgBFmlYLPTn 3yUw==
X-Gm-Message-State: AOAM530lU/iSrcsXpffDplDrfy9fD9fqMH/6j76vmDDETz+NVn4Cs2/+ qZMJyHonKHaamZC+xKh2LqVrHEFdlNPuDcLGr6E=
X-Google-Smtp-Source: ABdhPJx83s+Pt8eBVKVWLqbFFAHVJZ5Fat/MHuzvvYQtln7cKDKzh/gHuC5WMYcvV5y3y4ryFIwMLNYY2frYBxKWlHQ=
X-Received: by 2002:a1f:3250:: with SMTP id y77mr3804684vky.20.1616656607862; Thu, 25 Mar 2021 00:16:47 -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>
In-Reply-To: <CAM8feuSxttFqra9JpXXSKMqfmGUhz30+3eDQRtDpKPF-4pVmbQ@mail.gmail.com>
From: Adrian Gropper <agropper@healthurl.com>
Date: Thu, 25 Mar 2021 03:16:36 -0400
Message-ID: <CANYRo8iJfpF2nt4se3KNhe14B5c_+ndmwjFFAhw7ybnJa_Cq2A@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="000000000000d5e1b205be573244"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/8Da1hwXJK-7stxznealIL5iMRwU>
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:16:54 -0000

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