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

Fabien Imbault <> Sat, 20 March 2021 18:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B2E73A27E1 for <>; Sat, 20 Mar 2021 11:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Status: No, score=-7.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, RCVD_IN_DNSWL_HI=-5, 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 uoKJmK69Swby for <>; Sat, 20 Mar 2021 11:22:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 21EA43A27DF for <>; Sat, 20 Mar 2021 11:22:38 -0700 (PDT)
Received: by with SMTP id k8so9614193iop.12 for <>; Sat, 20 Mar 2021 11:22:38 -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=N5J8cf/uR+no5WH7IUJlTzbicem9xGosan9uvv/wJvM=; b=LmIQN4t6eDXYQV57jocSR0UiBorT0VT8zfSh7qzdQ+NRITinhOFI3b0Nnk9OYJ31y2 eMdKMCyzpnfW/+jpZJ6z7xnO0sWL4F9AiIV0rT96i3Oklz9UUzDmLXWaBFQK2UzGDqsl IJTwAxH3m41XGeNnob67rZBIAvxiudUYEN8gOjzvNHWqWM+aEQSCXlns5ekY81/s8crw 1mpR2B7H/V/NuUPsZTAI3d7Vbu1pX3tj8J99c4hxWlC4mRkoyK3j3J02WL7kQ2PJaT19 d7nWXpr+6VtgAJ0qiypgJKAUW/wEWwmHAxiq114VsAe69sQSe/YUpkmveIuijJuYSa7u GoQg==
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=N5J8cf/uR+no5WH7IUJlTzbicem9xGosan9uvv/wJvM=; b=QBdsyODqYrwWwDHzwgB5jAUVQdfoUUuB32B22Z9orTXYdcFgixGagXO7J7WaSdksJj kXGLI+Uydpifs978MGTQGLpqdA08K77yTyq36JalcPwFYZxFCuqxaGEWDsGLnCkS+m5p o7P2RCklLAXyV66Hy6hKYqLI0avYcxKNc7e59qwE0Xnz3QnyGHKn6daT2PZrezLvfAI+ baCZ1ZAaHC7QWYt56BNonozaJve/2pJs20f4gM2ANCU42Eu0cBDKvD7cegDYAWzVPKx+ tyWv8Q37eB7yLjRk69EH0zprchNzbArT22JC69RpOJ9S+TCETWB6ZEkPa990jGNUim2I FzgA==
X-Gm-Message-State: AOAM531ROK9qJJeqjwNy558JVn0v/sY4qfLsvwAD1HKm0fevQ+K8N9qq sgXjwzV408vsN31PLWRt5EDeL4bWUvKaO6ng7ZYc4ta48MM=
X-Google-Smtp-Source: ABdhPJzt0Y8mquCFUrbUbV+zBPyiIZYJLlaygbUDcFfp55LJVaV2IjBbvXfMDa9KDXq00kBBsmRTwa/ZmZiVCENH0kg=
X-Received: by 2002:a05:6602:2018:: with SMTP id y24mr6631759iod.74.1616264556611; Sat, 20 Mar 2021 11:22:36 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Fabien Imbault <>
Date: Sat, 20 Mar 2021 19:22:21 +0100
Message-ID: <>
To: Alan Karp <>
Cc: Adrian Gropper <>, GNAP Mailing List <>, Mark Miller <>
Content-Type: multipart/alternative; boundary="000000000000c28c1205bdfbea9b"
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 18:22:41 -0000

Hi Alan,

Thanks a lot. This looks good. I'll have a detailed look at zebra copy.

Actually I was suggesting a feedback to the RS only for the worst case
scenario: if the RO has the choice of AS and is different from the
end-user, then the client wouldn't be able to know which AS is to be


Le sam. 20 mars 2021 à 18:58, Alan Karp <> a écrit :

> You are close on the flow.  The only change is that the RO does not need
> to inform the RS that the RO is using an AS.
> The flow is described in our Zebra Copy tech report,
>, which, by the
> way, uses non-opaque tokens.  (Don't worry about the length.  The last 60
> pages are a walkthrough of the reference implementation.)  I believe that
> example is closer to the GNAP use cases than the one in the talk Adrian
> mentioned.  Also, I hope the different terminology isn't too confusing.
>    1. The owner of RS delegates a set of rights to the administrator of
>    the service, AS-RS.
>    2. RO contacts AS-RS and gets back a capability authorizing a specific
>    set of methods at RS.
>    3. RO can use that capability to invoke RS with any of the authorized
>    permissions.
>    4. RO can delegate a subset of those rights to a client, who can then
>    invoke the RS with any of the authorized permissions.
>    5. RO can delegate a subset of those rights to an AS-RO.
>    6. AS-RO can delegate a subset of those rights to a client based on a
>    policy specified by RO.
>    7. That client can invoke RO with any of the authorized permissions.
> Note that AS-RS doesn't need to know anything about the various
> delegatees.  It just needs to verify that the delegations are valid.
> Responsibility tracking follows those steps.  AS-RS will hold RO
> responsible for all uses of any token delegated from the one AS-RS gave
> RO.  Each delegator is responsible for knowing who to hold responsible for
> each of its delegations.  Say there's a $100 penalty for misuse, and the
> client in step 6 does something bad.  AS-RS will collect $100 from RO.
> It's up to RO to collect $100 from AS-RO and up to AS-RO to collect from
> the client.
> This approach is the only thing that makes sense.  What would RS or AS-RS
> do with the information that RO delegated to AS-RO?  AS-RS has no way of
> collecting from AS-RO; only RO does.
> --------------
> Alan Karp
> On Sat, Mar 20, 2021 at 3:52 AM Fabien Imbault <>
> wrote:
>> Thanks for the description.
>> Trying to summarize what a capability  flow would look like following
>> those ideas:
>> 1) RS issues a capability for the RO. For instance "view and download
>> photo".
>> 2) RO can delegate that capability (or an attenuated version) to the AS.
>> Say "view photo", possibly with some ambient conditions.
>> If the RO further wants to choose between a list of possible ASs, the RO
>> would have to signal its choice to the RS, which would then have to signal
>> it to the client (what we had called RS preflight in some discussions). So
>> the AS-RS relationship would be mediated via the RO (or more precisely its
>> agent).
>> 3) a core GNAP negociation takes place with the AS (traditional photo
>> example).
>> Is that correct? Do not hesitate to correct me if I didn't accurately
>> capture what you said.
>> (I volontarily put DID aside for now)
>> Steps occurring before 3 are optional (for reasons discussed before and
>> also because we can't assume all RSs would be able to support that).
>> Fabien
>> Le sam. 20 mars 2021 à 10:49, Adrian Gropper <> a
>> écrit :
>>> 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 RO.
>>> Adrian
>>> On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbault <>
>>> wrote:
>>>> 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