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

Benjamin Kaduk <> Sun, 21 March 2021 17:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 587943A1157 for <>; Sun, 21 Mar 2021 10:18:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.403
X-Spam-Status: No, score=0.403 tagged_above=-999 required=5 tests=[KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qbb-j6kNmTmt for <>; Sun, 21 Mar 2021 10:18:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E285B3A1154 for <>; Sun, 21 Mar 2021 10:18:13 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 12LHI0Xe029890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 21 Mar 2021 13:18:06 -0400
Date: Sun, 21 Mar 2021 10:18:00 -0700
From: Benjamin Kaduk <>
To: Adrian Gropper <>
Cc: GNAP Mailing List <>, Alan Karp <>, Mark Miller <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
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 17:18:15 -0000

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