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

Fabien Imbault <> Sat, 20 March 2021 08:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B3873A1D79 for <>; Sat, 20 Mar 2021 01:23:31 -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 7dLLoEw5m8mq for <>; Sat, 20 Mar 2021 01:23:29 -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 426753A1D74 for <>; Sat, 20 Mar 2021 01:23:29 -0700 (PDT)
Received: by with SMTP id h1so10179080ilr.1 for <>; Sat, 20 Mar 2021 01:23:29 -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=JmoXcq1g1J8HzITtTcemBfHNgDKQO+yPTq4iM432Sd8=; b=Wz2IDru6fNdp2+Av/yuXgLG3kR6u7oM117McpBp7OO+jZSg/qoprEF1S0mantGoanR p7jOkXdLc8bCakPataZ0D4sqWqFF5m9qmjWyeaPpmoyfMF0yOIUeeTy8wshhIFK0B29s Ab3yP0KXKg4tTsuB3fPfGzEvA7dbirkfmKROJJdQWIyzKyLEbjXFrHu4plQG6ctVnR+l +SHF2mStaMDpw9sFTwI7wpJsUp/xJBqWURLuXU4iqNa6HAyntXmyUYSS1KSej4NPUS2F 6Y+t6tsckSGkvOIpmSztC5r7OZNAZRH5EqNTs8nD952SSMGv+sLx0elHTBfzpCabH9D1 fiCQ==
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=JmoXcq1g1J8HzITtTcemBfHNgDKQO+yPTq4iM432Sd8=; b=Vzw4DGiQ6ryLwCEYp22wagy53mtMMemKXiih7EBalae3Xs21XN2dDOtmzNuaDpQoRD lMzPzjEMMrPqCS3YbEyeDkDeNsyS33i9AtT/tMHBCAu8W6J19D2QUorEDfga1+O++rG9 +tx6ej2fbta6AGUkgCt451wQlxaiSxHZZqlYwPqn3H4fFj8B+nw0jRZ6x0wQr3Hj3ITD E2RjOI/m6Gz/4C9qpl5IcmnBxfBEwg6dRZS/c8sPwrP6AhasqT2yw4OB0XZr1ZcLQtb7 ywga/TLywkm42RILUMGMhUL7QrPx5n00xBvy1cfcmfKhe47Qceynk8SITI6zKTfmtjrr UXLw==
X-Gm-Message-State: AOAM533ZWn6Dy78j3fLykpIC1tD9yIeojTBuqJGypxhXg4AuCD/0stT8 owb71+jHIN1UDkl7/HSyFdy84VMWaBZxClbezp0=
X-Google-Smtp-Source: ABdhPJxz8yQXcYmxrZvywR/4OYwoZsJELY48pDQifKL9TCFFQFIN8X43ryPoQ1JjQKYa6MlSMfcF9FmQXcVCLNpu5HI=
X-Received: by 2002:a92:1a11:: with SMTP id a17mr5690984ila.188.1616228607267; Sat, 20 Mar 2021 01:23:27 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Fabien Imbault <>
Date: Sat, 20 Mar 2021 09:23:14 +0100
Message-ID: <>
To: Adrian Gropper <>
Cc: GNAP Mailing List <>, Alan Karp <>, Mark Miller <>
Content-Type: multipart/alternative; boundary="0000000000000317af05bdf38c61"
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: Sat, 20 Mar 2021 08:23:31 -0000

Hi Adrian,

Calling to one AS per persona can only be optional, as we have no way, and
no wish, of knowing all the identities used by the RO.

I think this relates to the idea of the RO having its own distinct agent,
but I still don't understand how that would work (even re-reading the
thread in issue 145). Could you elaborate?


Le sam. 20 mars 2021 à 06:08, Adrian Gropper <> a
écrit :

> @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
> --
> TXAuth mailing list