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

Adrian Gropper <agropper@healthurl.com> Sat, 20 March 2021 14:13 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 A5C9B3A2410 for <txauth@ietfa.amsl.com>; Sat, 20 Mar 2021 07:13:26 -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_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 1HIcMsBsHZTB for <txauth@ietfa.amsl.com>; Sat, 20 Mar 2021 07:13:24 -0700 (PDT)
Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) (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 CFDD63A240E for <txauth@ietf.org>; Sat, 20 Mar 2021 07:13:23 -0700 (PDT)
Received: by mail-vs1-f52.google.com with SMTP id k14so5083647vsb.6 for <txauth@ietf.org>; Sat, 20 Mar 2021 07:13:23 -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=j6/VYLcHrAXgjwmBCKS5IL6SMyeoOov2mwj67d1U99g=; b=NA8+PpCPissMBE9isWos9/BU7MZYA9YSAjPDw7M8kBq5BderDh7526lahxviYDynWE SrIs3skXLUFnhM6Z5ALwxjV473cckuLRjEzLZxY1/sqnB+kXpbcwti7QrUdwbONEOuWc ssdtnmZj83jr9GWPFLwDrPXIfHEZenzly++r7ddpcq/zad3BCDG2WqD/ClcnUBBy1Bti PuMX/G6BL6Clqha6dm+Lu/1/mwF3zVcO8rwDNkw7IFBOBitiykgdk96dN4nddvNVhxuv mH3XAGZxU4XhpNl8iw3RG0XZKK6w7uXDRdl22Md8ogEXHgwfeW5jjg8bc42AlBb0qa6v w2Tg==
X-Gm-Message-State: AOAM532CX98qUxEhQ/TtgUgH38MrhueCKYCu2KmfKh2ylWxcXk5c3IzE cjZ6ltnsW9E6qRwhU4i/x2Xq2vUN52vJzSdtuX5AA0WXMWM=
X-Google-Smtp-Source: ABdhPJxHeRLjySdz+SahOQsB51TwaoX4phk2p79yRMIpGho2TNZfCR62fkr/fRZebD/W4MAg+lQvEpEWmgvaylKVY08=
X-Received: by 2002:a67:db84:: with SMTP id f4mr5702645vsk.20.1616249602771; Sat, 20 Mar 2021 07:13:22 -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> <CANYRo8ijHOSYJfrFS6FmtU1XPMvt4jmPqLC2M=-nYDDpSoV=kA@mail.gmail.com> <CAM8feuSCgsprirHuZSmag1LuHTK_3SeBo6ksSe1Kwd4HLKQPBA@mail.gmail.com> <CANYRo8jm0_obzL5kK_2WtAnUf9sRE=pEJzH3j3uf+my-=8hcEw@mail.gmail.com>
In-Reply-To: <CANYRo8jm0_obzL5kK_2WtAnUf9sRE=pEJzH3j3uf+my-=8hcEw@mail.gmail.com>
From: Adrian Gropper <agropper@healthurl.com>
Date: Sat, 20 Mar 2021 10:13:09 -0400
Message-ID: <CANYRo8hdMxfkMY+UXqYsTbWqNyX7eM-=iht0n=bs1R6=hU-idg@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="000000000000710d4005bdf86feb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/LIeceGwdrhB_KrQcuQOpeLy1XWM>
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 14:13:27 -0000

While we still wait, here’s yet another framing: When an RS gets a request
that it thinks it has adequate policies to evaluate, do it. If it does not
have adequate policies, refer the request to someone that might have
adequate policies and don’t worry about it, you might hear back or not.

Adrian

On Sat, Mar 20, 2021 at 9:55 AM Adrian Gropper <agropper@healthurl.com>
wrote:

> While we wait, I might add this other perspective: If the RS trusts an
> access token, then honor it. If the RS doesn’t trust the access token,
> contact an AS with adequate authority. If it knows no AS with adequate
> authority, deny the request, with malice.
>
> Adrian
>
> On Sat, Mar 20, 2021 at 8:42 AM Fabien Imbault <fabien.imbault@gmail.com>
> wrote:
>
>> Indeed I was asking because it's easy to get it wrong, so the feedback of
>> higher authorities (Mark or Alan) is most welcome!
>>
>> In the flow I was indeed expecting bearer tokens.
>>
>> Fabien
>>
>> Le sam. 20 mars 2021 à 13:03, Adrian Gropper <agropper@healthurl.com> a
>> écrit :
>>
>>> Fabien, that is not the way I think of capabilities working. I would
>>> prefer to leave the explanation to experts that have tried to teach me over
>>> the years. That’s, in part, why I recommended Alan’s 40 minute talk at the
>>> beginning of this thread.
>>>
>>> To hold us over until one of them responds, I think of capabilities as a
>>> token that is signed by the issuer so no trust is involved. If the RS
>>> issues a capability to the RO signed by the RS, then it’s a pure bearer
>>> token and any client that appears at the RS API with that capability will
>>> access the resource. That’s option 1.
>>>
>>> Option 2 is not based on capabilities. The RS stores a public key and
>>> trusts any token signed to that public key. The public key represents the
>>> identity of the RO or the AS that the RO delegated to. That’s opaque to the
>>> RS.
>>>
>>> So the difference between the two options is in who signed the access
>>> token. The RS can offer both options to the RO if they’re nice.
>>>
>>> Adrian
>>>
>>> On Sat, Mar 20, 2021 at 6: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
>>>>>>>
>>>>>>