[GNAP] Will GNAP support Zero Trust Architecture?

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

Return-Path: <agropper@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3D0C63A1A5E for <txauth@ietfa.amsl.com>; Fri, 19 Mar 2021 22:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 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] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id V9Xth9xTxehN for <txauth@ietfa.amsl.com>; Fri, 19 Mar 2021 22:07:56 -0700 (PDT)
Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com []) (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 329FB3A1A5D for <txauth@ietf.org>; Fri, 19 Mar 2021 22:07:55 -0700 (PDT)
Received: by mail-ua1-f53.google.com with SMTP id c13so3703778uao.10 for <txauth@ietf.org>; Fri, 19 Mar 2021 22:07:55 -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:from:date:message-id:subject:to; bh=jdDfqa1s6nihxHnU/TdGnK8I6UM4t3vFh/qVD1afxP8=; b=uVuKL8f+sj0yzO24vJuiWmv7qO7AL1TqYVQSoKUhkLryOi/1sckQ8Dta+9mccli025 gKGZvJXO8GzY3xvLAQ/Bk3UV/lODUflhPvVaY0A6jbW41JwLqESOs9Jp8eJrTUeY+Cwt 0iL53vh8boyF7MsSP/9zgTp6uxXZtSx+rTFubNEd7aXxvNtqK68qr1J3HF7RCpVaKAyi wDrDbUrPPUtp9A4mDKQc2vSjDiuIOV2Ahjrzumo2KvXtbXuQt/exNTqHkT1PK2HogqPM JJf/w/9aAbtIG9kew+iGgwChUeLzMwBDewC6wpKKq3riiqMTzHj4+riY44yPnSm60yAB cuZw==
X-Gm-Message-State: AOAM532Oc4u/+env34hy9viJrDb1m9cLUdSdg1nAKHu6xBmq6uMZzcmE kkdVfyFst4UNWbi1FiPgttxYBH1L+19yhKrcd1qsoXf9MrqB9Q==
X-Google-Smtp-Source: ABdhPJwCkY/s5GcghjRzPZDpmuYi92qcMO6kjlMj1ouF5u+2heyknyp4+09+Ok/mfBgN04JTVsfY8a5DUSoc9cccKGU=
X-Received: by 2002:a9f:280a:: with SMTP id c10mr903121uac.7.1616216873997; Fri, 19 Mar 2021 22:07:53 -0700 (PDT)
MIME-Version: 1.0
From: Adrian Gropper <agropper@healthurl.com>
Date: Sat, 20 Mar 2021 01:07:42 -0400
Message-ID: <CANYRo8jBZFVWyvAgVSWSmnuC+i1NaEkJEGWextzGB0xNFnD9fA@mail.gmail.com>
To: GNAP Mailing List <txauth@ietf.org>, Alan Karp <alanhkarp@gmail.com>, Mark Miller <erights@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000a79b6705bdf0d035"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/51c6aPYujfvD9K7dzOb_G6aY9uY>
Subject: [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 05:07:58 -0000

@Alan Karp <alanhkarp@gmail.com> 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

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

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.