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

Alan Karp <> Sun, 21 March 2021 02:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4FCA3A12B2 for <>; Sat, 20 Mar 2021 19:33:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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 ryby98304amF for <>; Sat, 20 Mar 2021 19:33:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C21F3A1274 for <>; Sat, 20 Mar 2021 19:33:18 -0700 (PDT)
Received: by with SMTP id o19so7097931qvu.0 for <>; Sat, 20 Mar 2021 19:33:18 -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=WHGXzYh289d5xWUSYIrksKTzW8dRbnPvnTLt9wCUOH4=; b=HQ4Y7SARsMoNHKzbrLUJmw+tZ3MCFUb9kshdpn3DZs6XCgE9aDBczYmRPsNWBwkOvz D+iBYua0NO088hBH6S1Uo8SbFI+hEskKY+rpAsppU7v/3wyb6mUXgn68aWzNVxqvBm5f ZuDuYacrYzg6x/Q+kJBvlREywBU3KWVo1usWkP9yT5WKclXN7fB4PSD2he1w4dvumj9U QkhPXoIQsAXBOAmBlCqu4V/EQQ1crSSgrwkRl/4cI2qNE4uXi2MdekW/CDQw/KOaaAG9 IXdBwp8BHr00qNwyDynFSJdt+BYJODidIe6dGtjauFwSQhL5NBxDmwSOw7SXw9K4xVDe TdzA==
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=WHGXzYh289d5xWUSYIrksKTzW8dRbnPvnTLt9wCUOH4=; b=OdfNZmj3Yr7LAkjMKaB8UqXQEaY/4HI1HujgmTarJnryaUvzPH2KZepRSNR0bEWWK9 fQbX/7Aul5llciAo2s4i6p74t1niDZmRrBsdoTV/MsKKT93142hreyRgGa3WvI/daHP3 5s7NhqHvr8QlmfxS5gxJI6mbSkuuUEBpXZv32Ug05w59dneia4iShUsNiBWKMeQmWeZu ETxC6kFyGiUXk+qs9kHYE7X+vwZrOsiSRLY348ihtqjtpOEDqUejYtV1oSODHKZXMK3+ U9eil3zsj6zpuJsSY44h7RUUKyZw4qJhRKWYSYv/xOpD+Shz27A70ZJKjQcu3bDROeMQ ajog==
X-Gm-Message-State: AOAM533qEB7Voc9KPp/eO2SD12Q1cge6UoFjQLIhdMWKGnhWf9rcfgix HYYBDg1jhUMAWQCnStZyixmE9w6zomA/NRSdzFOmgTFKhjc=
X-Google-Smtp-Source: ABdhPJzDbOWMFs1xIZ3tM3sVRaF4UfR2FfAeenEz3o13VMG4h6NXoJNcIu3HEWSaDyWdRw0FLS34YYmIvfPh6loGtt0=
X-Received: by 2002:a0c:eac9:: with SMTP id y9mr15805926qvp.58.1616293996769; Sat, 20 Mar 2021 19:33:16 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Alan Karp <>
Date: Sat, 20 Mar 2021 19:33:05 -0700
Message-ID: <>
To: Adrian Gropper <>
Cc: GNAP Mailing List <>, Mark Miller <>
Content-Type: multipart/alternative; boundary="00000000000087b3ec05be02c599"
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: Sun, 21 Mar 2021 02:33:26 -0000

Adrian Gropper <> wrote:

> Lastly, at the level of attenuation, I would choose a relationship with
> RSs that issue to me capabilities that can be attenuated not only by my AS
> but also by the requesting parties that receive them as part of an access
> token.

The ability to attenuate at each delegation is key to enforcing least

Alan Karp

On Fri, Mar 19, 2021 at 10:07 PM Adrian Gropper <>

> @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.
> Beyond that fairly obvious principle, we could spread our interactions
> among as many services as possible. We already do this when we spread
> assets across multiple banks, internet services across redundant platforms,
> or we use LinkedIn, Twitter, and Facebook with limited overlap in social
> graphs.
> At the next level down, we want to manage resources at each RS using least
> authority in order to make AS policy vulnerabilities easier to spot and
> debug. My AS might get multiple capabilities or access to scopes from an
> RS, each one carefully labeled with its intended uses so that the policy
> engine of my AS could be structured to consider requests relative to only
> one capability or scope family at a time. For example, in issuing health
> record authorizations, I might separate the behavioral health capabilities
> from capabilities to access the physical parts of my record at a given
> hospital's GNAP RS API.
> Lastly, at the level of attenuation, I would choose a relationship with
> RSs that issue to me capabilities that can be attenuated not only by my AS
> but also by the requesting parties that receive them as part of an access
> token.
> Adrian