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

Adrian Gropper <> Sat, 20 March 2021 09:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D294F3A1EB3 for <>; Sat, 20 Mar 2021 02:49:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NRefAzdjZrer for <>; Sat, 20 Mar 2021 02:49:38 -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 9E2863A1EB4 for <>; Sat, 20 Mar 2021 02:49:38 -0700 (PDT)
Received: by with SMTP id j15so2673164vkc.1 for <>; Sat, 20 Mar 2021 02:49: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=ywy/n5Oo0OSfdi2iivrF0D7zGNE2cGnZUxb0qg1Qz1c=; b=uagDryNE8LAYhfpFVlsSYIqS5ugHtVKKwwIdZC2Z7za6XB/lbnsdLc4t5zmhBNeOcv iAgNB5eyb0qIadymzMBV1hFhTO7vQn/CY6APV8XktP3WBPsgBLSIFZ+5OQ0F5zT8HeOC HvfGmujREYz++KGqQwTaZLst4lVOAk3Lee9AhFNChTLveX9GhT4pfCUTMW/52gpM5cqg qr7svmPnMMDxXFb2PWKC6yBPoWUQw1CKkoCYp3I1ngC7VNAtIgCg40YxGPbxYnWSQ+/u tWOjty1rxa4ziUghJYMhdHqKVxs50YzxCl+ThN4NmjJUlzNUlS1HLkSXVwvCTS71mvlj v/hQ==
X-Gm-Message-State: AOAM532DzzMsXjMCJrHXx7S/Fm9K2Yqm44ZVCShVIPQiy4WSpYwFSZMw d5xO53rANiGuq9X0nmMCegHiVF9ROXAFZ4gdZb0=
X-Google-Smtp-Source: ABdhPJxdtiHySS07JmzUaHabXAR2VjF7fGSXp0eRLW7K96iQC7Q+3PdLoyOgSvy61E6O4KeqVa1is4+Clc5adn/kxFs=
X-Received: by 2002:a1f:914c:: with SMTP id t73mr4901582vkd.7.1616233777304; Sat, 20 Mar 2021 02:49:37 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Adrian Gropper <>
Date: Sat, 20 Mar 2021 05:49:25 -0400
Message-ID: <>
To: Fabien Imbault <>
Cc: Alan Karp <>, GNAP Mailing List <>, Mark Miller <>
Content-Type: multipart/alternative; boundary="0000000000002b997305bdf4c0c7"
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 09:49:41 -0000

Hi Fabien,

Yes, it’s optional and adding meaningful options is one way to consider the
ethical imperative

If I understand Alan’s teachings, the RS has the option to either issue one
or more capabilities to the RO or to store some identity-related
information about the RO such as the DID of the RO and, by reference, the
AS service endpoint controlled by that DID.

Given some capabilities, the RO can either deal with them manually or hand
them to an AS. Either way, the RS has no idea of the RO’s choice until it
receives a token from some end user. This seems to be what the Letters of
Transit in Casablanca were all about.

If, on the other hand, the RO chooses to give 5e RS a DID, a self-sovereign
identifier, instead of taking some capabilities, then the RS has the
expectation  to trust tokens signed by that DID.

It’s my hope that GNAP can allow an ethical RS to offer both choices to the


On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbault <>

> 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?
> Thxs
> Fabien
> 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