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

Fabien Imbault <> Sat, 20 March 2021 20:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2283D3A2A6B for <>; Sat, 20 Mar 2021 13:58:29 -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 O4qauM-ZVzN0 for <>; Sat, 20 Mar 2021 13:58:26 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7CE6A3A2A6A for <>; Sat, 20 Mar 2021 13:58:26 -0700 (PDT)
Received: by with SMTP id d10so4507300ils.5 for <>; Sat, 20 Mar 2021 13:58:26 -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=LSOeN7EcXavv0OkFIfIJphk5seO6RmCUFWJKs+2p2w4=; b=Awm99kYwaoiTKa0OR/xvN1gdRAgasoE7d7ElPAfnCOKGdl2MQsnyxd6sCGDjgq/VTZ 2FrWDAG3666o3qjEHGmGIHj+H5uXJrrpgGaU6VCP2jQtGS1/3qtuUMBh72LJKImtBBZ7 cYxvYjESeMzCcsD71/9cBW1+mdBcX19YYvAphsQ4N+9ykXswGboszWmomGeyBN7kCwek dR7n78WmNr/YmlIxBq7aJ3bu2ph9B7KsXS7Gnsh+ltlpx+HN4I8FMNLjt6mY5YlK01cf lKkWwcoyAARnXzVjgg8fvqmbGveF0J+p+EPeyU+TsUSmR6y6Jjoxd6KlaF06r2kbXO1s FNRg==
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=LSOeN7EcXavv0OkFIfIJphk5seO6RmCUFWJKs+2p2w4=; b=ZCWtyt8+NFlnNePYq8pnvKyhn9Wx0E+DcNOjkYwkOsiXjHMmB5Iks4Dd11u0+tlvmV eJMl63BKeSu0CnD2D6PeyYGRTbQJDc+rhWAfVvfbmvHkm7kWlH2IJbruFy27T/sdJi3Y 0Y1wCD3ReAIR7emfZB5e9u9TiC+O4GWLkzJVxhMghA8gnkWUs76nDs9qgjfB1wOS+FFq ZUTThBbROTFNcUzlPTKySBCzvfjgdiORIQOjMF6gxXQMSQLFet6kN/3RoZD3CnXgl+UN uvzitUFDOtgyYI4sCtxEcRKWg1ftrlK0k6iTSDDBcyOkfcdbzth4o716K5jLl/RMGwtH hlfA==
X-Gm-Message-State: AOAM533LQoAr6edtduhz8U+1TlKuksdBLLvRVmtFFqjx9G0DVG1sFXlc uFgVhZDrlU12vEXf1DEFZ7OyFWtiIb2Sc5ZtGM8=
X-Google-Smtp-Source: ABdhPJy6AcbTjxXTxopYFScsRSs1dWSVdXVFSnR5rakLI2/lE2e8Ke2VaBq49sadT24+x7k0FcNkCNAYOliTEUqRnwY=
X-Received: by 2002:a92:1a11:: with SMTP id a17mr7199989ila.188.1616273904781; Sat, 20 Mar 2021 13:58:24 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Fabien Imbault <>
Date: Sat, 20 Mar 2021 21:58:11 +0100
Message-ID: <>
To: Adrian Gropper <>
Cc: Alan Karp <>, GNAP Mailing List <>, Mark Miller <>
Content-Type: multipart/alternative; boundary="000000000000f44e5705bdfe179b"
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 20:58:29 -0000

OK fine then.

I just remembered that you suggested a choice between several AS-RSs by the
RO. If that's not the case, there's no problem.


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

> To be clear, I'm suggesting that GNAP standardize two separate flows if
> necessary and give the RS the option of supporting one or both of them.
> - Option 1 is capabilities and exactly as Alan just outlined where the RO
> does not need to inform the RS that it is using an AS.
> - Option 2 is an RO-controlled AS as might be linked to a DID service
> endpoint.
> Adrian
> On Sat, Mar 20, 2021 at 1:58 PM Alan Karp <> wrote:
>> 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