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

Adrian Gropper <> Mon, 22 March 2021 18:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 70CDA3A1022 for <>; Mon, 22 Mar 2021 11:14:43 -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 SCPJt55F7Kdy for <>; Mon, 22 Mar 2021 11:14:39 -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 9A69B3A0FE5 for <>; Mon, 22 Mar 2021 11:14:38 -0700 (PDT)
Received: by with SMTP id x8so5834681ual.6 for <>; Mon, 22 Mar 2021 11:14:38 -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=vSN82Pf8mKAECyaVO/xoIwJeVXxytroysqNc8F0imlQ=; b=GZDz7ZhN/8E4ow2O+vxWq2YKt7R5KBvyJVhit5Vmg2ToRjjUIuDAAScxAuBHvN8b4U lV1AmGbVtDvpUa/PZuAx9jEs+9WREZUICPenXpietOp4UxqXA3hkqkj15DNTfBO4R7mZ H498dJR5ta2I6h73YIIuRmUTJVNdlnQa5TXoD0RlTWAIhIni4kllmXRyg3MS8p5UHnsp Al6ba6AJe5nHr1zw3FCAGhVnYl2xRYyqLXItYHpZYlqJif9sC7FAw3K/RYIBTIy08xLE p1hzS7u+Y0DyRxfK+GUOOJ/jWHmSw2CtdhYHxild/RH8SPQPVak2+JAxZYR1f4+dkwDK 2P4g==
X-Gm-Message-State: AOAM531S+V9DUcmB9upfk18ir7+TFHUkR6+TRBMsKSov8wMNxeiQglTi EGnQCpNHsOwz9+IV042CiQIGffEmOjymRH85XuJMx2ghhzQ=
X-Google-Smtp-Source: ABdhPJzl4I25enFFJFEdkorJFR5Av6vNk5iom6XnrYvdXg5dDPaDKGis7Nno6bmIEp7w7RDlFmQqUVgCbH0kd9Lz8uY=
X-Received: by 2002:ab0:5e5:: with SMTP id e92mr1050651uae.70.1616436877190; Mon, 22 Mar 2021 11:14:37 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Adrian Gropper <>
Date: Mon, 22 Mar 2021 14:14:24 -0400
Message-ID: <>
To: Justin Richer <>
Cc: Benjamin Kaduk <>, Alan Karp <>, GNAP Mailing List <>, Mark Miller <>
Content-Type: multipart/related; boundary="000000000000de671a05be240913"
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 18:14:44 -0000

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.


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