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

[Josh Mandel <[e-mail]>]

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.