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

Fabien Imbault <> Wed, 24 March 2021 21:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C5D03A0B8C for <>; Wed, 24 Mar 2021 14:20:58 -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 QR1U_JmRyO4D for <>; Wed, 24 Mar 2021 14:20:53 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F47E3A0B8A for <>; Wed, 24 Mar 2021 14:20:44 -0700 (PDT)
Received: by with SMTP id u10so394030ilb.0 for <>; Wed, 24 Mar 2021 14:20:44 -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=bBDzr7azpSL7d0T/FrRBGfxvTZ/lW+3qrY68hgndwys=; b=A+b9TTNU+QjrJ/S+W8oOxqzGR+8cVdngkAkSi8c+fUb+tIJcgAqJ+spgRiyrRgaiIb ihntoQhk8BErFYAg5yJ+rKCgNnAE9eJhucFjLStF9xICVZAjDBFnkfFxKtuAXH5YiGN7 JcSqEzJ/1bjkaHOsMbDwmA9Q2LYCPPYkDhsknpMJp6T4HC3NuYORlOJ1+lPOBXhFfR7f 8JfLhrkRWr0n8ef6xAaR5g4rLYl/kk6oo0EJd8Dm3FS5iAL20aiUMnBGAqCyq5Wgtwga UylciegwpaaYfAWRcHzEPGIhchXpQgcuybbGUttdfcMJod0JE/wLF7Z0W162FQgRyNaD mtVg==
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=bBDzr7azpSL7d0T/FrRBGfxvTZ/lW+3qrY68hgndwys=; b=HFsSckRerilDMA8/NZSwUegGEIK3LDuOfikdhNZ/gzEA8rJ+pGIvy9uWY5ZBHPnsF9 epZgIjslY4vneor53RcDs2hp9cXbnrG2PBDuE5o5dThPptpW4mnAGpsRbmudNGFJlv+b yyW590AojG5yMNsovElwN4x3gPbDPByf39e1amtgbJPyXAJRxSSZ2cNkkgM6WmLbnz/L 0Ieg7V+Io5yUwOo1yFEaXvIudQCdvBfQlCeXhxAH6tMlo13RxihufxHXh9pon3BWhMsP hDT+l3TtfsgTlX4mPWc/o2N8eIOgZ8q3DOHllDpB3e8fO3G42ebfYdvMUrXZxF4Pl61b 3JPg==
X-Gm-Message-State: AOAM532ubnZKv+iU2J38ydVUx6pe9nEc3IBS2g5TWimBH7Wilm+Cgoky oKw5XPM2Pg/3ZNC8CST0lZwxqYAlzLqsNrP7k5GOo2AKIIA=
X-Google-Smtp-Source: ABdhPJylaux+3jmY6AFDNxZosKO52X590CJ+UgKMCnBVZFPGUARFgnzOhsT8M3GSsthJeZn1pLy9bqhj6QvmoXbqFmA=
X-Received: by 2002:a92:4b05:: with SMTP id m5mr3732055ilg.188.1616620842751; Wed, 24 Mar 2021 14:20:42 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Fabien Imbault <>
Date: Wed, 24 Mar 2021 22:20:29 +0100
Message-ID: <>
To: Alan Karp <>
Cc: Justin Richer <>, Adrian Gropper <>, Benjamin Kaduk <>, Mark Miller <>, GNAP Mailing List <>
Content-Type: multipart/alternative; boundary="0000000000001198af05be4edfbd"
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: Wed, 24 Mar 2021 21:20:58 -0000

Isn't that what the AS is supposed to be, only with the caveat that the
policy is defined locally?


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