Re: [GNAP] Accounting for Resource Owner in RS::AS interactions

Adrian Gropper <> Mon, 27 September 2021 18:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 295933A1417 for <>; Mon, 27 Sep 2021 11:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 Y2OpnV0k-e0a for <>; Mon, 27 Sep 2021 11:40:49 -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 E55FC3A1409 for <>; Mon, 27 Sep 2021 11:40:48 -0700 (PDT)
Received: by with SMTP id j13so17570957qtq.6 for <>; Mon, 27 Sep 2021 11:40:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JLxtM/wvszpZemoaY3h3f8fZ2ExMrRTjgT0TrEsmaUM=; b=3sw0NOXonB/oY8Wu+f6Q9YJAG1QeQ2oEv8Kq8bnm8Y6FK3SncvGbGltcL8KuGaFoZx VoJENEQmY18cSkz4xRFvBar3pZNJybhYsBgJMMHp94pykDnel2zwOklHs5VkfH+tsWzB 116c5E4+rSVxgTEi/xqPRyNAjvQZRyjCENDTg3Is6btdWUYHyI1cVJmXA1reHTmTm6d5 rPc9cfoKI5+malcad6RZx731PCIpLtkIN6Sasto6ufRPPK2oNheFplnA68sEDEhT0H33 F4BoMrJrTENVUVwcrjs/s8KNeedN7090/Z4idUDftVi4GrLEdkafISbDwczGJHHQG0nv qQhw==
X-Gm-Message-State: AOAM532reRvlTCRdaqlVgcUFgtnbLW4Yc39hWnB2LWKVrJwLXGQPf6/C en9rXLUJ0DoIScl4UEOftWifzOE8XMNdDC7BqaI=
X-Google-Smtp-Source: ABdhPJy6wCwYyfVSWzcaZSbtribAomwVmGL07LUpt/VaO8RZZzmA1FpkFsqzNfkFvRU2wJbpy05IWTkKeFZIp+3tDvI=
X-Received: by 2002:ac8:720f:: with SMTP id a15mr1443457qtp.84.1632768047782; Mon, 27 Sep 2021 11:40:47 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Adrian Gropper <>
Date: Mon, 27 Sep 2021 14:40:34 -0400
Message-ID: <>
To: Josh Mandel <>
Cc: GNAP Mailing List <>
Content-Type: multipart/alternative; boundary="0000000000007d1ee905ccfe6f47"
Archived-At: <>
Subject: Re: [GNAP] Accounting for Resource Owner in RS::AS interactions
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: Mon, 27 Sep 2021 18:40:53 -0000

This was being discussed in this thread

In my opinion, Scenario 2 or RS-issued capabilities that allow the RO to
effectively choose their AS is the only solution.

Scenario 1, even if it could be supported by GNAP, does not deal with the
data minimization privacy issue. As an RO, I don't want to share my
policies with a multi-tenant RS. In UMA, we spent almost a decade trying to
deal with "cascading ASs" and similar dreams of RS-restricted agency for
the convenience of the RS. If GNAP is to be a delegation protocol, then
restricting the RO's delegation options will always be a problem because
such restrictions are a matter of law, not protocol.

In my opinion, GNAP would be much easier to understand if we defined the RO
as the entity that controls policy at the GNAP AS. An AS in the same trust
domain as an RS is just a federation of RSs and we're back to OAuth.

- Adrian

On Mon, Sep 27, 2021 at 1:56 PM Josh Mandel <> wrote:

> Hi All,
> I'm interested in exploring how GNAP can/does/might account for the
> Resource Owner associated with specific protected resources, in scenarios
> where a single AS is trusted by multiple independent RS's (specifically in
> scenarios where these RS's don't know or trust one another). Justin
> suggestd I might reach out here.
> My sense is that there are security considerations related to these
> questions, and perhaps some best practices or even areas where the core
> spec's data models could be enhanced to support these scenarios. I'm not
> proposing anything in particular at this stage; just trying to get the lay
> of the land.
> See assumptions and scenarios below.
> -Josh
> --
> *Assumptions. *I'll focus on a very simple API from the RS perspective: a
> standardized file access API where resource servers would like to make
> access control decisions based on access tokens whose RARs look something
> like:
> {
>   "type": "file-access",
>   "actions": ["read"],
>   "location": ["{{URL of one protected file}}"]
> }
> ---
> *Scenario 1. *Consider the case where a single RS manages files owned by
> multiple end users. The RS uses a single AS for all files (but the AS also
> serves other untrusted RS's). Each RO is allowed to set authorization
> policies for their own files. In this scenario, how does the AS learn which
> RO is responsible for setting policies for each file, so it can present
> Alice with a list of current policies, allow her to review/tweak access,
> etc? (If an AS is confused on this point, there's a risk that Bob can set
> policies for Alice's files.) It's possible that the Resource Registration
> API could be extended to model this kind of ownership, if both servers have
> some interoperable way to communicate user identities. I'm not sure if
> there are existing patterns to recommend here? It's also very important for
> the RS to know, whenever it receives an access token, that the RS is an
> intended audience for that token. The RAR "locations" aren't enough to
> accomplish this, unless the AS has a reliable scheme in place to prevent
> one RS from crafting RARs that refer to resource locations within another
> RS.  And as the spec says, the AS introspection endpoint needs to ensure
> that access tokens are "appropriate for presentation at the identified RS".
> But that's especially challenging when a single access token can include
> multiple RARs, potentially intended for different RS's (which appears to be
> allowed by the base spec). And for structured token formats where
> introspection isn't required, the same questions hold; is there existing
> work on this?
> *Scenario 2. *Now consider the case where 10 organizations each manage a
> File Sharing RS. Each RS hosts files for multiple ROs, and the ROs get to
> choose which AS should be trusted for their own files. In this context, I
> suppose the workflow that introduces the RS to the AS can be mediated by
> the RO, so that the RO is logged into both systems when making the
> introduction, and the RS can essentially register a new client instance
> with the AS for each RO who decides to establish a connection. This pattern
> has the advantage that there's no confusion about *who* controls a given
> resource -- but perhaps there are other, better ways to accomplish this.
> --
> TXAuth mailing list