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

[Adrian Gropper <[e-mail]>]

This was being discussed in this thread
https://mailarchive.ietf.org/arch/msg/txauth/nhV4f59Xf5EaZ8c-YjkWWN6oCr0/

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>