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

Adrian Gropper <> Sun, 21 March 2021 19:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47EFD3A091C for <>; Sun, 21 Mar 2021 12:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.501
X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iyz3TLB6P486 for <>; Sun, 21 Mar 2021 12:38:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 42DF53A091B for <>; Sun, 21 Mar 2021 12:38:52 -0700 (PDT)
Received: by with SMTP id c2so4894938uaj.3 for <>; Sun, 21 Mar 2021 12:38:52 -0700 (PDT)
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=7km2GcSCtNLnLloTfRixW19L730RFupc7r3kCSrAMBo=; b=LDDt9G2Z9QCFX4t/EMxVJvL6V2qTQHNfCpbaduJPeMrH1C4pJ8+l9W0ZQKzGT0OOn4 iaQICypWnrkv/GMkjyPD69Xu/3nmQK01B8HWn3VrR2QvLvrOK6/+7w2t5Pm8nsWW+dLl t5W9NVIf35+eB4BX0HNtjVqPmBSairEngLB9mgPMA3ywvc2bXn9j0ooahDjD0ZTjYXWf jS0tkT03h2NKgJjkpV6YCXlO4YD9siLbM5ru5KyK4vuKZF6VuTceTPigFrJBPfjTUC7Y Hjxm7ow0X+fulGX/w4mSyapvA/yBTDMg4hdB9uIRAQQupZIR+swyXfC7Fy28kThWXEIE y2og==
X-Gm-Message-State: AOAM531I2w7bigvoG+s+TnxyMaCkJW8N8PiRLp2cqMN4m3ujxSoJuPii 0WCtg6QtA8yhXYxdAhyxmmnXyJote3Tlx+FhAgY=
X-Google-Smtp-Source: ABdhPJwr4C1wJtmJaEFB3IqXStf3puZ8L5LlQralbhyx20NWdelA8mTvyKVohoCxsExuqm9hwsddZBbzboSdJST2loQ=
X-Received: by 2002:ab0:30a3:: with SMTP id b3mr3101472uam.0.1616355531192; Sun, 21 Mar 2021 12:38:51 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Adrian Gropper <>
Date: Sun, 21 Mar 2021 15:38:39 -0400
Message-ID: <>
To: Fabien Imbault <>
Cc: Benjamin Kaduk <>, Alan Karp <>, GNAP Mailing List <>, Mark Miller <>
Content-Type: multipart/alternative; boundary="000000000000447dbe05be1119bc"
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: Sun, 21 Mar 2021 19:38:54 -0000

In the SSI community, we have had more than a year of discussion, often
intense, over the relationship between DIDs (decentralized identifiers),
service endpoints (and their protocols) in DIDs (how many and what do they
point to) and concepts like "herd privacy" that are essential to avoiding
unwanted correlation and traffic analysis. With the recent ascension of DID
core to Candidate Recommendation We consider some of these
issues settled. Along the way we've created various privacy analyses and
had review by W3C. Section 10 is a great place to start as we consider the
privacy of protocols like GNAP CR-did-core-20210318

tl:dr My personal perspective after all of this work, is that mediator
roles are a useful option at the intersection between a data model like DID
and a protocol like GNAP. There were two classes of DID service endpoint
protocols that stood out: messaging and authorization. Either one might be
enhanced by the DID controller introducing a mediator but it doesn't change
the core aspects of the messaging or authorization protocol itself. YMMV


On Sun, Mar 21, 2021 at 2:34 PM Fabien Imbault <>

> Hi Ben
> Very good question.
> The core protocol probably will be able to elude providing an answer,
> focusing on singular requests.
> Any extension covering AS-RS relationships will have to handle its socio
> technical impact.
> Fabien
> Le dim. 21 mars 2021 à 18:18, Benjamin Kaduk <> a écrit :
>> On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
>> > @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.
>> Thinking about how least authority/least privilege would apply to GNAP
>> seems like a useful exercise.  I do want to point out some potential
>> pitfalls with one-AS-per-persona that we can also be aware of.  If
>> one-AS-per-persona becomes one-persona-per-AS as well, then the AS's
>> identity in effect also serves as a persona identity and there are privacy
>> considerations to that.  If, on the other hand, the
>> multiple-personas-per-AS (presumably corresponding to multiple humans)
>> route is taken, we should consider whether that would lead to various
>> (e.g., market) forces driving consolidation to just a handful of
>> super-popular AS services.  That topic is a current matter of concern to
>> some IETF participants.
>> Thanks,
>> Ben
>> --
>> TXAuth mailing list