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

Adrian Gropper <> Mon, 22 March 2021 20:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A3783A0E19 for <>; Mon, 22 Mar 2021 13:13:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.501
X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MT2IyFMg80iy for <>; Mon, 22 Mar 2021 13:13:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E0BE3A0E12 for <>; Mon, 22 Mar 2021 13:13:20 -0700 (PDT)
Received: by with SMTP id l22so8161178vsr.13 for <>; Mon, 22 Mar 2021 13:13:20 -0700 (PDT)
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=mZw/Xx3txfMy5bDN/GhRs6+CVIfomJvOq0ytxE+fgzk=; b=gjifvmxJQYLO8H0tW7u2b1CjOsIUJ+oJhCozvmwn4Wxl95CkWuiXtQH5KzeasyTdas tD4mmEKgMym2hwnZwbMcRRuhuHL2PMFbQUBVDI8JvEjax36kTZZlp9fesKg94iZ5oTfi KRlB+ONnedfvgh+N3v1Z865HpufvRYszhoVNqMp3Ykzu4ue2laVkRgRTLytXNuXihwpI Pms9s6dlFRZsahyh5+HwAcQai7FIwKZrA4XlaX50+yXvRGNYhDmeyN0tftDTYLb+VkCf xG4jrj0hXnUQ4kuAEnrOdVoiOXbb3sGoO3JeX21DXw9SuNSAe2qv6tZ/CVO8rUkLQc+I augw==
X-Gm-Message-State: AOAM5324VU6ZM6QmECTUx2pWej/PbehQuaSCyKs85cgtjDqTqZ+QPFx/ Q1NnpGLHLHDBcj+QeQULAMDJF/Uzw96gbLJlmrg=
X-Google-Smtp-Source: ABdhPJy68yQqoDNp0GD5K0Br2+3U9mzxAnlzpQ4pgwy7KamJQPlatFH0ndDwttTh7RWd+Wi2n9hXpJVimzab+8R3wvA=
X-Received: by 2002:a05:6102:24a:: with SMTP id a10mr1418897vsq.39.1616443999391; Mon, 22 Mar 2021 13:13:19 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Adrian Gropper <>
Date: Mon, 22 Mar 2021 16:13:07 -0400
Message-ID: <>
To: Justin Richer <>
Cc: Benjamin Kaduk <>, Alan Karp <>, GNAP Mailing List <>, Mark Miller <>
Content-Type: multipart/alternative; boundary="0000000000006215d905be25b262"
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: Mon, 22 Mar 2021 20:13:25 -0000


Indeed, we do have a problem with the way terminology is being used in this
conversation. To help with that, you asked me to provide a use-case rather
than arguing over terminology. I did that with the HIPAA API Task Force
use-case in the thread you started that has gone silent since I tried to
summarize the discussion here: FPIrji3uAQDLkGtqVvC-PreMWbI

In another approach, Alan Karp has tried to find a consensus around using
AS-RS and AS-RO terminology. That seems to have gone quiet as well.

As far as I can tell, Justin, you are insisting that the RO share
authorization policies with an RS (or AS-RS) that the RO does not control
in the sense that you expect requesting parties to present their claims and
purposes to the AS-RS and then have some expectation that the AS-RS can
convey the request to a separate policy decision point that is controlled
by the RO. I would call that PDP the AS-RO but other names are certainly

Please, how do I as an RO keep the RS (or AS-RS) as ignorant as possible of
the request content and my RO policies?


On Mon, Mar 22, 2021 at 2:40 PM 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