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

Adrian Gropper <agropper@healthurl.com> Sat, 20 March 2021 21:06 UTC

Return-Path: <agropper@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2413A2A87 for <txauth@ietfa.amsl.com>; Sat, 20 Mar 2021 14:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
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_DNSWL_NONE=-0.0001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0W8TSTfZ4quK for <txauth@ietfa.amsl.com>; Sat, 20 Mar 2021 14:06:51 -0700 (PDT)
Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 399793A2A82 for <txauth@ietf.org>; Sat, 20 Mar 2021 14:06:51 -0700 (PDT)
Received: by mail-vk1-f175.google.com with SMTP id w63so2910077vkf.11 for <txauth@ietf.org>; Sat, 20 Mar 2021 14:06:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ep2oFqKoyxpfT5QPtlo91DmbyFrx60FP1EM4TBjF9fA=; b=BTU6E4alE+yagOY4i24o9AW7kNJIq2wCD+z/uh4/Q4kzU86wNDtaqga8x+fa7dtcx4 02M4100diRORjkcZVeAmCiV53+wpQEevSxslULYzodoWbgLE+l/a1AX0td66VWYnp6bp LV0enAK0+KMzvmr/4ml0UO9x/+Hb6yDalM8y2bkjFToBFDOvbyhdAZbFEPZmko1EXCNA 3qUSFSf6i5dz5xbP0vHFyXcdEniWqA4S+xw0uiqLMiV8mzlYrk247ip6zo3VrEQXzsrv Ukva6dpkHLtlCMI4aPphJTfo67vh3qdhrI1GXVzX656Kv8K1RCaC3DmowZ1EnuRsSf0y VbiQ==
X-Gm-Message-State: AOAM533Iafv/otgFcA4WOkNpQZX1ANe4nD0xOczc7muM+lwAq2Xhm508 5cD3EoXauSlDS59tPWHfrQ6XtrSVBzvh/Qj/ZbU=
X-Google-Smtp-Source: ABdhPJz51sw5T0KCrYsydw0v+THaEuxOvhzOp1fkX5wI3y42+tAdzo3eXcmzD07DA4p6kg1omjH/okRfu0UsZzXiBVQ=
X-Received: by 2002:a05:6122:889:: with SMTP id 9mr5921756vkf.10.1616274409789; Sat, 20 Mar 2021 14:06:49 -0700 (PDT)
MIME-Version: 1.0
References: <CANYRo8jBZFVWyvAgVSWSmnuC+i1NaEkJEGWextzGB0xNFnD9fA@mail.gmail.com> <CAM8feuSUmfL8thipf=hV-QHtkuy-Zh5txbAspvO9vxm6P3MgZg@mail.gmail.com> <CANYRo8gPcPqjmonr_bJOgF_bS5E-o-o2ZVN3WfQCwbnwv0jPQw@mail.gmail.com> <CAM8feuTS5SCLVdO0ZZ-RJOWV08=gEeAvC8hrdUD0c9L8AHjYtQ@mail.gmail.com> <CANpA1Z1-9yCPMaY53LQYT9jEsGif-kdZ6RtCxL+z2K8sUpKQHQ@mail.gmail.com> <CANYRo8hahimCTBbqV5FvMZnwTX6DdsdNstz4zbhU3N-YpOG4OA@mail.gmail.com> <CAM8feuRpOkqz=74i_y6-Yr623WniYNsB=MYwp_SRH_1xJsxVkA@mail.gmail.com>
In-Reply-To: <CAM8feuRpOkqz=74i_y6-Yr623WniYNsB=MYwp_SRH_1xJsxVkA@mail.gmail.com>
From: Adrian Gropper <agropper@healthurl.com>
Date: Sat, 20 Mar 2021 17:06:38 -0400
Message-ID: <CANYRo8ibPWCFJpXQAMF=-HNV0GXb=Y2m8xfOGqSuCN4H7KwTdg@mail.gmail.com>
To: Fabien Imbault <fabien.imbault@gmail.com>
Cc: Alan Karp <alanhkarp@gmail.com>, GNAP Mailing List <txauth@ietf.org>, Mark Miller <erights@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000000e1dd905bdfe3636"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/d0GNWpi3mfc_ENneJ-xlHVrZBAc>
Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture?
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Mar 2021 21:06:54 -0000

You remember accurately, Fabien. It was one of the ways I was trying to
explain my suggestion. Sorry to mislead. I hope the case I'm making with
Alan's help is clearer now.

Adrian

On Sat, Mar 20, 2021 at 4:58 PM Fabien Imbault <fabien.imbault@gmail.com>
wrote:

> 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.
>
> Fabien
>
> Le sam. 20 mars 2021 à 21:20, Adrian Gropper <agropper@healthurl.com> 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 <alanhkarp@gmail.com> 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,
>>> https://www.hpl.hp.com/techreports/2007/HPL-2007-105.pdf, 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 <fabien.imbault@gmail.com>
>>> 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 <agropper@healthurl.com>
>>>> a écrit :
>>>>
>>>>> Hi Fabien,
>>>>>
>>>>> Yes, it’s optional and adding meaningful options is one way to
>>>>> consider the ethical imperative http://www.cybsoc.org/heinz.htm
>>>>>
>>>>> 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 <
>>>>> fabien.imbault@gmail.com> 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 <agropper@healthurl.com>
>>>>>> a écrit :
>>>>>>
>>>>>>> @Alan Karp <alanhkarp@gmail.com> shared a talk about the Principle
>>>>>>> Of Least Authority (POLA) in a recent comment
>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693
>>>>>>> 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
>>>>>>> TXAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>
>>>>>>