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

Fabien Imbault <> Thu, 25 March 2021 10:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D747C3A1D27 for <>; Thu, 25 Mar 2021 03:41:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nv0wjivRUSRN for <>; Thu, 25 Mar 2021 03:41:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B28AA3A1D26 for <>; Thu, 25 Mar 2021 03:41:05 -0700 (PDT)
Received: by with SMTP id e8so1416515iok.5 for <>; Thu, 25 Mar 2021 03:41:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sUESc7pL8ZXU1j3ysHyfSxtcksFrvT0Y8KEdo5TF6ek=; b=OisIJC60W31OtP+z3pfZFmZ/f9G3Be0MbWL0tHpEXDwBsbZ+xJnftxPmV64RlrXtEH S6I3E7/K43lm79jXxtGhm2YfXpIGGaRGXWFUy0Zmd/AcG3beUih+XkokJSdunS8ZSZe6 +bh2UTg0KYS+gOzw5GzcNVqvGXgtplo0olwMMauMb/TXUaQ2dntp5FsxOiaLDR1UHC2y USx2Dt9k0u9S113oK9Zg5XP9xbklvlAZwZbydM7q+RYI/0L/jMwGsu0tuD/KFwjQ5AQt faJ/XdAkHKcotTywJTTeMuAkgX0Sdol9ervTfjt1B+s/BowweAlgKdKDaNMdndqKYkdB PmXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sUESc7pL8ZXU1j3ysHyfSxtcksFrvT0Y8KEdo5TF6ek=; b=qF5/34DaW165OH2NK67gLPj2i88TkSVP57bz22bVx+Bc86OTTAHvVmaSELHd7FE8F2 ly3rwtS/K7Bma+5cBL7vKvgbuQW9NpgYW4iuj0TUSA8StpmAElCsqKbY8KoTvFLouBd/ ELeRfxZRNMfwoeymOzz3bX+KJyNyy7FqP2K41xxafTo6gk+Uh38rIyB9RXBgzJdwgYvD alD3BlELvyj8f3sYKxK19+dwlituVxb8Y+jXGNqAxSwOdMu4KYq8xo/qwleIYyJYGrcn kRv1AtVp72PdCq2Cz1hdoOY+Oal7tSwvzvSWNj/uXXzy+EqApDEHd7D8CqKQv4TiRWaG sEZg==
X-Gm-Message-State: AOAM533VRQkZYvFeYhdTziQIEyis5uNWwDITZhJ9CmTqLiMqhaPQClSv ENFxOIP5q8ePXe0BWPtEhNOYVEvL0T9ZsxaKmJI=
X-Google-Smtp-Source: ABdhPJx7ktIXPCezmdwwfVEjNImhG9XP4Etns5+Ima+GS8ChQ5I6661wHOnUwdr0Cn5xJb6I8ayi+tI5F/RG3FEP8cI=
X-Received: by 2002:a02:c6b4:: with SMTP id o20mr6929655jan.124.1616668863777; Thu, 25 Mar 2021 03:41:03 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Fabien Imbault <>
Date: Thu, 25 Mar 2021 11:40:52 +0100
Message-ID: <>
To: Adrian Gropper <>
Cc: Alan Karp <>, Benjamin Kaduk <>, GNAP Mailing List <>, Justin Richer <>, Mark Miller <>
Content-Type: multipart/alternative; boundary="00000000000058511305be5a0dee"
Archived-At: <>
Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Mar 2021 10:41:11 -0000

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)


On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault <>

> 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 <>
> 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 <>
>> 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 <>
>>> 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 <
>>>>> 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 <>
>>>>> 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 <
>>>>>>> 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 <
>>>>>>>> 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 <
>>>>>>>>> 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 <
>>>>>>>>>> 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 <
>>>>>>>>>>> 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 <>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Adrian Gropper <> 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 <
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Thank you for creating the issue. My definition of AS is
>>>>>>>>>>>>> independent of AS-RO or AS-RS.
>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>> 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 <>
>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> Hi Alan and Adrian,
>>>>>>>>>>>>>>>> I've created issue AS-RO policy delegation (
>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> Fabien Imbault <> 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 <
>>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> Justin Richer <> 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 <
>>>>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian
>>>>>>>>>>>>>>>>>>>>>> Gropper wrote:
>>>>>>>>>>>>>>>>>>>>>> >> @Alan Karp <> shared a talk
>>>>>>>>>>>>>>>>>>>>>> about the Principle Of Least
>>>>>>>>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment
>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>> >> 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 mailing list
>>>>>>>>>>>>> --
>>>>>>>>>>>> TXAuth mailing list