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

Alan Karp <> Tue, 23 March 2021 15:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 829E43A11DE for <>; Tue, 23 Mar 2021 08:15:36 -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 O2x7h2LWqmkX for <>; Tue, 23 Mar 2021 08:15:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 106CA3A11DD for <>; Tue, 23 Mar 2021 08:15:32 -0700 (PDT)
Received: by with SMTP id y18so14665862qky.11 for <>; Tue, 23 Mar 2021 08:15:32 -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=tbDhQjIIit6gYv35LmLI39+BmksslvFwjOkN/MobPSE=; b=V1ijQkQNb4g7khJsJz/GTL9LDhufAx6prTVxTMYXgXSWxNFZ95FmO2g4XMPEvHFNQe PX3NinopQWKLBcniI4+DbTX348h5+VnWvIh1sDjafcno2xhjUWEOTpJRUpMTVLyyRTWu 9rsD9d+nWjuZfWoyCKSSYEaxBVmocwCKtOIo4vwJenEurIw6pUUHSftwY+sA5MAbeAQx xD1XKaAK1tWIVhNAnKBeoYjAsxlRr+klKOEM/A3M9akWkWQVHGcGqSS3EqqfnyTd2Uh4 C31CbBhs4vvvRvJclN0LqVLgMvX65xRQ2CRqPgs+/gdpiJYZBmVAhuwJYHtIGF4nSdaj wMHQ==
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=tbDhQjIIit6gYv35LmLI39+BmksslvFwjOkN/MobPSE=; b=pfJ5qUolfudmTYeGhJ8Kv1xe9N8Q3PPAQuvGF9Tc6Cg1ku3Z6aiWZmHhhkCssi8jYY fl2ILrryuGr7e0Yu6JSSjH8f4NzX3OlHFuJQ5UpOlKIf7oa0LtdEBFibFlofm7FDGrKU n4g/e5SWyFwrDk9X9vNNNTLTRM2ET7jlc2m8XWLKiGx2SAfSNqKwj3X9Mmz81OcGfAsC V0OX1yBAoTfdRMQkYAErtUkWM0t/FWsMh9bVy9IMygkjO+yMq/g7pqI2IM3YoCF5kvza Wu6XqDekOrw4yfbQJnnqZAJ0J2/EQvStrJMEXFO582P7xLhjhH5hWgiFpiRmEd7wb/ov 3JMw==
X-Gm-Message-State: AOAM530VRTPfM/0zHuvkTtO+b5IDK6f6Zrslk+o6lXODNsvoPUSzPjZd GvwNUudcKRSUc2ryuzxgHvzHOknF4+4mry9ujDI=
X-Google-Smtp-Source: ABdhPJzehTOd7AJirGv3c2wACV7zde6Va9HlCFyk42k5PPNh35ws/Pn9AFkUBEqF3YMwIjG9l6Cure81d1e5lLl8Zpw=
X-Received: by 2002:a37:3c8:: with SMTP id 191mr5824708qkd.90.1616512528792; Tue, 23 Mar 2021 08:15:28 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Alan Karp <>
Date: Tue, 23 Mar 2021 08:15:17 -0700
Message-ID: <>
To: Fabien Imbault <>
Cc: Justin Richer <>, Adrian Gropper <>, Benjamin Kaduk <>, Mark Miller <>, GNAP Mailing List <>
Content-Type: multipart/alternative; boundary="0000000000000dc22105be35a768"
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: Tue, 23 Mar 2021 15:15:37 -0000

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

> 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