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

From: Josh Mandel <[email-masked]>
Date: Mon, 27 Sep 2021 12:56:18 -0500

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.

---

From: Adrian Gropper <[email-masked]>
Date: Mon, 27 Sep 2021 14:40:34 -0400

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 <[email-masked]> wrote:

> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 28 Sep 2021 14:57:28 -0400

Hi Josh, thanks for bringing up this use case. An AS protecting several different unrelated RS’s is absolutely in scope, as this is a common deployment for OAuth 2 today. If I understand everything you’re asking, currently GNAP would allow everything here, but it doesn’t specify the details of every part of it. I’m going to reply to your scenarios inline below. Apologies in advance for the long email, there’s a lot to unpack here!

> On Sep 27, 2021, at 1:56 PM, Josh Mandel <[email-masked]> 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.
> 
> 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"],
> 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?

Setting and updating policies are outside the scope of GNAP core, including any interfaces for doing so.

The policies are controlled at the AS and enforced by the RS. It’s really up to the individual deployments how and where to make that split: an AS could issue tokens that are simply tied to the specific data, the result of processing the security context of the delegation. Or the AS could send over all the context information to the RS to let it make its own decisions entirely, while the AS only has an idea of something existing and not who owns or controls it. Or something in between. And all of these are functionally the same whether you’re introspecting or using structured tokens, so I’m not going to get into the differences here.

Doing this statically would be pretty easy, since the decisions can just be set in code and executed. Doing it dynamically feels a lot harder and more interesting. There are a lot of pieces that need to be fulfilled to even get to this point, and I’ll try to add some thoughts on each: 

- How does the AS know who Alice is? In OAuth, it’s assumed that Alice can “log in” to the AS using her account. In GNAP we also allow that but further let Alice have other ways of interacting with the AS, and doesn’t assume that Alice has an “account” at the AS in a traditional sense. Even so, it’s likely in this scenario that the AS will have some set of identifiers that it has bound to Alice, which can be associated with that policy.

- How does the RS know about the AS? GNAP does offer some discovery for the technical connections (https://www.ietf.org/archive/id/draft-ietf-gnap-resource-servers-01.html#name-rs-facing-as-discovery), but more important is the question of how the RS decides to trust the AS to protect any given resource. In your scenario this sounds like a configuration time decision, but it might not always be.

> (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?

- How does the AS know about what the RS is protecting? GNAP allows the RS to dynamically introduce a new resource set to the AS and get back a reference for it (https://www.ietf.org/archive/id/draft-ietf-gnap-resource-servers-01.html#name-registering-a-resource-set <https://www.ietf.org/archive/id/draft-ietf-gnap-resource-servers-01.html#name-registering-a-resource-set>), and like you, I could see this being expanded with an ability to say “this RO / set of ROs controls this resource set” as part of that registration step. As long as the identifiers aligned, it would let the AS do some enforcement at token issuance time. But that really isn’t meant to set policies, it’s meant to allow an RS to register a set of rights with a simple identifier (like a scope with a random value). Perhaps a different API is actually needed for policy management? And with that in mind, it would only be needed if we wanted the AS to make sure Bob is never prompted for one of Alice’s files at the AS, ever. If you don’t want that information to leak to the AS, you can allow Bob to get an ineffective token for Alice’s file resource, and count on the RS to say “hey you aren’t Alice, go away”. Again, this goes back to where you draw the enforcement lines, which often has more to do with the nature of the API you’re protecting than anything.

- How does the RS know how to associate a specific resource with “Alice”, and not “Bob"? This requires the RS to know who “Alice” is and know that a given file is hers to control. Doing this dynamically feels really difficult

- How do the RS and AS agree that “Alice” is the same person with the same identifiers? It’s obvious that simply trusting a global identifier here won’t solve it on its own — confusion remains trivial, it would just take an RS to apply Bob’s global identifier to Alice’s data, or for Bob to get assigned Alice’s identifier by a bad AS. But GNAP does have a whole notion of “subject identifiers” that are scoped to the AS’s trust domain that can be used here: if the RS refers to Alice by an identifier known to the AS, and it trusts the AS to enforce that binding for Alice, then it will work.

> 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?

The ‘locations’ field on its own isn’t enough for this, but it can be a place to hold identifiers for each RS. These need not be URLs to the APIs in question, though in practice I’d expect them to be. It then also begs the question of how the RS identifiers came to be, and if they’re then required for this type of processing. 

> 
> 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.

That was what UMA tried to do with resource set registration, in a way. It was awkward from a technology perspective, and it made RS owners nervous in a lot of ways to have a new AS introduced. I appreciate the ideology, but to this day I don’t believe it’s realistic to implement or deploy.

I think a better pattern is to allow introduction of “Alice” at the AS level instead of at the RS level. In other words, Alice doesn’t bring her own “AS”, but she could bring her own identity and policy to the AS that protects the RS. That way the RS-AS relationship can be more tightly aligned, but the user capabilities are greatly expanded. It changes the fit of the components from what we might be used to, but I strongly believe there’s a lot of promise in this pattern. And in fact, we see a similar pattern in OAuth 2 today with API Gateways that can be configured to allow federated logins, for example.

Finally, I think there’s an even more interesting scenario: when Alice says that Bob should be able to access her stuff. Who does she tell and who needs to care? There are a lot of ways to slice this, but this jumps to my mind immediately:

 - Alice has a resource A at the RS, which is protected by the AS
 - The AS has a policy that says Alice can authorize client instances to access resource A
 - The AS also has an interface for Alice to set additional policies
 - Alice says to the AS that a user identified as Bob can also access A
 - When either Alice or Bob come to the AS, the AS can figure out from this policy to create an access token that can access A
 - The RS doesn’t need to know about Alice or Bob at all, only whether the token is good for accessing A

 — Justin

---

From: Josh Mandel <[email-masked]>
Date: Tue, 28 Sep 2021 14:20:19 -0500

Thanks Justin -- this whole response is extremely helpful. I particularly
appreciate your very clear declaration of scope and intention:

*> That was what UMA tried to do with resource set registration, in a way.
It was awkward from a technology perspective, and it made RS owners nervous
in a lot of ways to have a new AS introduced. I appreciate the ideology,
but to this day I don’t believe it’s realistic to implement or deploy.*

I agree entirely with this assessment, and I agree that some tighter degree
of AS::RS coupling is needed to support real-world system design.
Understanding that this UMA-like level of RS::AS flexibility is *not* the
design intent for GNAP alleviates several of my concerns in one fell swoop.
I should mention that for readers familiar with UMA (or at least... for me)
this was not clear from reading GNAP; I came in assuming GNAP intended to
cover this space.

On Tue, Sep 28, 2021 at 1:57 PM Justin Richer <[email-masked]> wrote:

> Hi Josh, thanks for bringing up this use case. An AS protecting several
> different unrelated RS’s is absolutely in scope, as this is a common
> deployment for OAuth 2 today. If I understand everything you’re asking,
> currently GNAP would allow everything here, but it doesn’t specify the
> details of every part of it. I’m going to reply to your scenarios inline
> below. Apologies in advance for the long email, there’s a lot to unpack
> here!
>
> etc?
> The policies are controlled at the AS and enforced by the RS. It’s really
> up to the individual deployments how and where to make that split: an AS
> could issue tokens that are simply tied to the specific data, the result of
> processing the security context of the delegation. Or the AS could send
> over all the context information to the RS to let it make its own decisions
> entirely, while the AS only has an idea of something existing and not who
> owns or controls it. Or something in between. And all of these are
> functionally the same whether you’re introspecting or using structured
> tokens, so I’m not going to get into the differences here.
>
> Doing this statically would be pretty easy, since the decisions can just
> be set in code and executed. Doing it dynamically feels a lot harder and
> more interesting. There are a lot of pieces that need to be fulfilled to
> even get to this point, and I’ll try to add some thoughts on each:
>
> - How does the AS know who Alice is? In OAuth, it’s assumed that Alice can
> “log in” to the AS using her account. In GNAP we also allow that but
> further let Alice have other ways of interacting with the AS, and doesn’t
> assume that Alice has an “account” at the AS in a traditional sense. Even
> so, it’s likely in this scenario that the AS will have some set of
> identifiers that it has bound to Alice, which can be associated with that
> policy.
>
> - How does the RS know about the AS? GNAP does offer some discovery for
> the technical connections (
> https://www.ietf.org/archive/id/draft-ietf-gnap-resource-servers-01.html#name-rs-facing-as-discovery),
> but more important is the question of how the RS decides to trust the AS to
> protect any given resource. In your scenario this sounds like a
> configuration time decision, but it might not always be.
>
>
> (If an AS is confused on this point, there's a risk that Bob can set
> there are existing patterns to recommend here?
>
>
> - How does the AS know about what the RS is protecting? GNAP allows the RS
> to dynamically introduce a new resource set to the AS and get back a
> reference for it (
> https://www.ietf.org/archive/id/draft-ietf-gnap-resource-servers-01.html#name-registering-a-resource-set),
> and like you, I could see this being expanded with an ability to say “this
> RO / set of ROs controls this resource set” as part of that registration
> step. As long as the identifiers aligned, it would let the AS do some
> enforcement at token issuance time. But that really isn’t meant to set
> policies, it’s meant to allow an RS to register a set of rights with a
> simple identifier (like a scope with a random value). Perhaps a different
> API is actually needed for policy management? And with that in mind, it
> would only be needed if we wanted the AS to make sure Bob is never prompted
> for one of Alice’s files at the AS, ever. If you don’t want that
> information to leak to the AS, you can allow Bob to get an ineffective
> token for Alice’s file resource, and count on the RS to say “hey you aren’t
> Alice, go away”. Again, this goes back to where you draw the enforcement
> lines, which often has more to do with the nature of the API you’re
> protecting than anything.
>
> - How does the RS know how to associate a specific resource with “Alice”,
> and not “Bob"? This requires the RS to know who “Alice” is and know that a
> given file is hers to control. Doing this dynamically feels really difficult
>
> - How do the RS and AS agree that “Alice” is the same person with the same
> identifiers? It’s obvious that simply trusting a global identifier here
> won’t solve it on its own — confusion remains trivial, it would just take
> an RS to apply Bob’s global identifier to Alice’s data, or for Bob to get
> assigned Alice’s identifier by a bad AS. But GNAP does have a whole notion
> of “subject identifiers” that are scoped to the AS’s trust domain that can
> be used here: if the RS refers to Alice by an identifier known to the AS,
> and it trusts the AS to enforce that binding for Alice, then it will work.
>
>
> 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?
>
>
> The ‘locations’ field on its own isn’t enough for this, but it can be a
> place to hold identifiers for each RS. These need not be URLs to the APIs
> in question, though in practice I’d expect them to be. It then also begs
> the question of how the RS identifiers came to be, and if they’re then
> required for this type of processing.
>
>
> That was what UMA tried to do with resource set registration, in a way. It
> was awkward from a technology perspective, and it made RS owners nervous in
> a lot of ways to have a new AS introduced. I appreciate the ideology, but
> to this day I don’t believe it’s realistic to implement or deploy.
>
> I think a better pattern is to allow introduction of “Alice” at the AS
> level instead of at the RS level. In other words, Alice doesn’t bring her
> own “AS”, but she could bring her own identity and policy to the AS that
> protects the RS. That way the RS-AS relationship can be more tightly
> aligned, but the user capabilities are greatly expanded. It changes the fit
> of the components from what we might be used to, but I strongly believe
> there’s a lot of promise in this pattern. And in fact, we see a similar
> pattern in OAuth 2 today with API Gateways that can be configured to allow
> federated logins, for example.
>
> Finally, I think there’s an even more interesting scenario: when Alice
> says that Bob should be able to access her stuff. Who does she tell and who
> needs to care? There are a lot of ways to slice this, but this jumps to my
> mind immediately:
>
>  - When either Alice or Bob come to the AS, the AS can figure out from
> this policy to create an access token that can access A

---

From: Justin Richer <[email-masked]>
Date: Tue, 28 Sep 2021 15:35:18 -0400

On Sep 28, 2021, at 3:20 PM, Josh Mandel <[email-masked]> wrote:
> 
> Thanks Justin -- this whole response is extremely helpful. I particularly appreciate your very clear declaration of scope and intention:
> 
> I agree entirely with this assessment, and I agree that some tighter degree of AS::RS coupling is needed to support real-world system design. Understanding that this UMA-like level of RS::AS flexibility is *not* the design intent for GNAP alleviates several of my concerns in one fell swoop.

To be clear, this is my own take on the goals of GNAP vs. experience with UMA, and the stance I’ve been advocating for here for some time. I think GNAP could allow that, in that GNAP doesn’t :require: a tight coupling per se, but it also doesn’t assume a completely loose coupling or force the protocol through those hoops for all other use cases. UMA tried to do the latter, but just about every UMA deployment I saw didn’t make use of that loose coupling, but you still had to go through the bits of the protocol that were built just in case that happened. 

It’s a goal of GNAP to learn from the good and bad of previous protocols, including UMA, and this is one area that I think we can improve.

> I should mention that for readers familiar with UMA (or at least... for me) this was not clear from reading GNAP; I came in assuming GNAP intended to cover this space.
> 

I think what might be confusing here is that GNAP does intend to cover the use case space of having a user delegate to another user, and externalizing a lot of the user rights aspects of the ore delegation process too. But instead of doing it through “everyone brings their own AS” type of things, GNAP is trying to do it through “the AS can now be flexible enough to get a lot of different information”. There were some slides on this a while back:

https://datatracker.ietf.org/meeting/110/materials/slides-110-gnap-core-protocol-slides-00 <https://datatracker.ietf.org/meeting/110/materials/slides-110-gnap-core-protocol-slides-00>

Starting at slide 35 you’ll see diagrams and points of some of the alternatives. I know the meeting is recorded but I”m not sure where that lives if you want to review it.

 - Justin

> On Tue, Sep 28, 2021 at 1:57 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Sep 27, 2021, at 1:56 PM, Josh Mandel <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi All,
>> 
> - How does the RS know about the AS? GNAP does offer some discovery for the technical connections (https://www.ietf.org/archive/id/draft-ietf-gnap-resource-servers-01.html#name-rs-facing-as-discovery <https://www.ietf.org/archive/id/draft-ietf-gnap-resource-servers-01.html#name-rs-facing-as-discovery>), but more important is the question of how the RS decides to trust the AS to protect any given resource. In your scenario this sounds like a configuration time decision, but it might not always be.
> 
> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>

---

From: Adrian Gropper <[email-masked]>
Date: Wed, 29 Sep 2021 00:27:28 -0400

Josh and Justin,

>From a privacy perspective, your glee over not having the RO specify the AS
to the RS is troubling. Why would the RS care about privacy unless mandated
in some way? (I'm assuming mandates are out of scope for GNAP :-).

The privacy problem is simply data minimization. As an RO, I should not
have to share my policies with the RS because all the RS needs is the
access token. If the RS is unwilling (or whatever you mean by "nervous",
above) to trust a random AS simply because the RO trusts it, then we're
left with capabilities. Imagine a typical RS serving millions of ROs. The
policy database would be a gold mine in so many ways. Traffic analysis by
the RO might still be a problem and will also need to be considered.

If specifying the AS is not an option, the RO associated with a resource
MUST be given a full set of capabilities on demand. The RO can then pass
some or all of those to whatever AS they trust with their policies and then
that AS can issue attenuated access tokens with or without further
delegation rights to any client they choose.

GNAP core must choose either or both arbitrary AS or capabilities and maybe
explain "nervous" in a way that people can understand.

- Adrian

On Tue, Sep 28, 2021 at 3:35 PM Justin Richer <[email-masked]> wrote:

> I agree entirely with this assessment, and I agree that some tighter
> degree of AS::RS coupling is needed to support real-world system design.
> To be clear, this is my own take on the goals of GNAP vs. experience with
> UMA, and the stance I’ve been advocating for here for some time. I think
> GNAP could allow that, in that GNAP doesn’t :require: a tight coupling per
> se, but it also doesn’t assume a completely loose coupling or force the
> protocol through those hoops for all other use cases. UMA tried to do the
> latter, but just about every UMA deployment I saw didn’t make use of that
> loose coupling, but you still had to go through the bits of the protocol
> that were built just in case that happened.
>
> It’s a goal of GNAP to learn from the good and bad of previous protocols,
> including UMA, and this is one area that I think we can improve.
>
> I should mention that for readers familiar with UMA (or at least... for
> me) this was not clear from reading GNAP; I came in assuming GNAP intended
> to cover this space.
>
>
> I think what might be confusing here is that GNAP does intend to cover the
> use case space of having a user delegate to another user, and externalizing
> a lot of the user rights aspects of the ore delegation process too. But
> instead of doing it through “everyone brings their own AS” type of things,
> GNAP is trying to do it through “the AS can now be flexible enough to get a
> lot of different information”. There were some slides on this a while back:
>
>
> https://datatracker.ietf.org/meeting/110/materials/slides-110-gnap-core-protocol-slides-00
>
> Starting at slide 35 you’ll see diagrams and points of some of the
> alternatives. I know the meeting is recorded but I”m not sure where that
> lives if you want to review it.
>
>  - Justin
>
>
>> *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
>> - How does the AS know who Alice is? In OAuth, it’s assumed that Alice
>> can “log in” to the AS using her account. In GNAP we also allow that but
>> - How does the AS know about what the RS is protecting? GNAP allows the
>> RS to dynamically introduce a new resource set to the AS and get back a
>> reference for it (
>> - How do the RS and AS agree that “Alice” is the same person with the
>> same identifiers? It’s obvious that simply trusting a global identifier
>> here won’t solve it on its own — confusion remains trivial, it would just
>> take an RS to apply Bob’s global identifier to Alice’s data, or for Bob to
>> get assigned Alice’s identifier by a bad AS. But GNAP does have a whole
>> notion of “subject identifiers” that are scoped to the AS’s trust domain
>> that can be used here: if the RS refers to Alice by an identifier known to
>> the AS, and it trusts the AS to enforce that binding for Alice, then it
>> will work.
>>
>>
>> That was what UMA tried to do with resource set registration, in a way.
>> but to this day I don’t believe it’s realistic to implement or deploy.
>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 29 Sep 2021 12:16:29 +0000

Adrian, 

Once again, I believe you are conflating the technical roles of the protocol (AS, RS) with the parties that would fulfill those roles. What you describe as the RS entity in your solution is, in reality, an AS/RS pair. What you describe as the RO's chosen AS is what GNAP calls out as an input into the AS. This is why I keep saying that it's the interaction and consent phase of GNAP where things like SSI and policy descriptions and user-to-user delegation come into play. It's a different model from UMA, and I believe it's a model that works much better and fits reality. 

The AS issues tokens that are trusted, the RS trusts and executes those tokens. Giving an unknown party complete security control over your API is terrifying, and we've already seen that what actually happens is that people build in a internal AS to handle that case anyway. It's why we have things like security assertions and token exchange and application gateways. 

Software delegation protocols, like OAuth and GNAP, aren't particularly well suited to the user delegation problem on their own, because you can't have a user present a technical input. You can however make explicit places within the protocol for those inputs to be expressed, and that's what we are trying to do with GNAP. 

You can absolutely build out the model I'm describing in privacy preserving ways, and I will argue that it will have significantly better security properties when compared to letting a user pick their AS. 

So, let the RS dictate who it will listen to tokens from, and allow the AS to get its information about what those tokens are for, and when to issue them, from a variety of places. 

- Justin
________________________________________
From: Adrian Gropper [[email-masked]]
Sent: Wednesday, September 29, 2021 12:27 AM
To: Justin Richer
Cc: [email-masked]; GNAP Mailing List
Subject: Re: [GNAP] Accounting for Resource Owner in RS::AS interactions

Josh and Justin,

>From a privacy perspective, your glee over not having the RO specify the AS to the RS is troubling. Why would the RS care about privacy unless mandated in some way? (I'm assuming mandates are out of scope for GNAP :-).

The privacy problem is simply data minimization. As an RO, I should not have to share my policies with the RS because all the RS needs is the access token. If the RS is unwilling (or whatever you mean by "nervous", above) to trust a random AS simply because the RO trusts it, then we're left with capabilities. Imagine a typical RS serving millions of ROs. The policy database would be a gold mine in so many ways. Traffic analysis by the RO might still be a problem and will also need to be considered.

If specifying the AS is not an option, the RO associated with a resource MUST be given a full set of capabilities on demand. The RO can then pass some or all of those to whatever AS they trust with their policies and then that AS can issue attenuated access tokens with or without further delegation rights to any client they choose.

GNAP core must choose either or both arbitrary AS or capabilities and maybe explain "nervous" in a way that people can understand.

- Adrian

On Tue, Sep 28, 2021 at 3:35 PM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
On Sep 28, 2021, at 3:20 PM, Josh Mandel <[email-masked]<mailto:[email-masked]>> wrote:

 - Justin

On Tue, Sep 28, 2021 at 1:57 PM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
Hi Josh, thanks for bringing up this use case. An AS protecting several different unrelated RS’s is absolutely in scope, as this is a common deployment for OAuth 2 today. If I understand everything you’re asking, currently GNAP would allow everything here, but it doesn’t specify the details of every part of it. I’m going to reply to your scenarios inline below. Apologies in advance for the long email, there’s a lot to unpack here!

On Sep 27, 2021, at 1:56 PM, Josh Mandel <[email-masked]<mailto:[email-masked]>> wrote:

Hi All,

-Josh

--

{
  "type": "file-access",
  "actions": ["read"],

---

- How does the AS know about what the RS is protecting? GNAP allows the RS to dynamically introduce a new resource set to the AS and get back a reference for it (https://www.ietf.org/archive/id/draft-ietf-gnap-resource-servers-01.html#name-registering-a-resource-set), and like you, I could see this being expanded with an ability to say “this RO / set of ROs controls this resource set” as part of that registration step. As long as the identifiers aligned, it would let the AS do some enforcement at token issuance time. But that really isn’t meant to set policies, it’s meant to allow an RS to register a set of rights with a simple identifier (like a scope with a random value). Perhaps a different API is actually needed for policy management? And with that in mind, it would only be needed if we wanted the AS to make sure Bob is never prompted for one of Alice’s files at the AS, ever. If you don’t want that information to leak to the AS, you can allow Bob to get an ineffective token for Alice’s file resource, and count on the RS to say “hey you aren’t Alice, go away”. Again, this goes back to where you draw the enforcement lines, which often has more to do with the nature of the API you’re protecting than anything.

 — Justin

--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

---

From: Adrian Gropper <[email-masked]>
Date: Wed, 29 Sep 2021 09:26:08 -0400

Please help me understand what's happening in privacy terms so that I might
be able to explain it to others.

inline... and apologies for the long email

On Wed, Sep 29, 2021 at 8:16 AM Justin Richer <[email-masked]> wrote:

> Adrian,
>
> Once again, I believe you are conflating the technical roles of the
> protocol (AS, RS) with the parties that would fulfill those roles. What you
> describe as the RS entity in your solution is, in reality, an AS/RS pair.

Could be, but from a privacy perspective what matters is trust domains. If
the AS/RS pair is operated by the same entity or federation, then they are
just an RS from a privacy perspective. If that trust domain can aggregate
and make inferences from millions of policies belonging to ROs then we have
a privacy problem and are introducing a compromise in privacy in the name
of security. Let's try to avoid that.

What you describe as the RO's chosen AS is what GNAP calls out as an input
> into the AS.

It sounds like this "input" above is a policy management input rather than
a request input. My point just above is that the RS has no valid reason to
aggregate policies across ROs. It's not just an information minimization
issue but also separation of concerns that helps audits and zero-trust
architectures.

> This is why I keep saying that it's the interaction and consent phase of
> GNAP where things like SSI and policy descriptions and user-to-user
> delegation come into play. It's a different model from UMA, and I believe
> it's a model that works much better and fits reality.
>

I don't understand the basis of this statement. You're now introducing
user-to-user delegation. If User 1 is making requests to the RS (as RO)
then is User 2 making requests to what you're calling the AS/RS or to an AS
chosen by User 1 (RO)?

If I understand delegation via capabilities, User 3 would be making a
request to an AS chosen by User 2.

>
> The AS issues tokens that are trusted, the RS trusts and executes those
> tokens.

That's one way to do it, by defining the RO as the party that chooses and
specifies which AS is trusted. The other way is capabilities where the
token structure allows attenuation as determined by AS policy.

Giving an unknown party complete security control over your API is
> terrifying,

SSI is terrifying but the choice of the RO to delegate to an agent they
choose is what makes it self-sovereign and less terrifying. Agency can
always be pro se or fiduciary (to use the terms that apply to legal
representation). The difference between self-sovereign and fiduciary is
regulation and GNAP must not presume regulation is available or effective.

> and we've already seen that what actually happens is that people build in
> a internal AS to handle that case anyway. It's why we have things like
> security assertions and token exchange and application gateways.
>

I probably agree with you here but, as just above, this seems out-of-scope
for GNAP.

>
> Software delegation protocols, like OAuth and GNAP, aren't particularly
> well suited to the user delegation problem on their own, because you can't
> have a user present a technical input.

If the "technical input" is what I'm calling the policy management input to
the AS, I have no problem with GNAP keeping it out of scope. That technical
input could be a web form or an API or, heaven forbid code or XACML. It's a
directive, not a request. What mitigates the privacy issue is that the RO
can choose the AS which tends to keep both the RS and the AS honest.
Obviously, there is a cost to the RO if switching ASs involves digesting
some other policy framework for the same RS and delegation goals but
standardizing the policy management data model is not a task we should take
up in GNAP core.

You can however make explicit places within the protocol for those inputs
> to be expressed, and that's what we are trying to do with GNAP.
>

Sure. Policy management inputs by the RO is what defines the AS from my
privacy perspective. How else could it be?

>
> You can absolutely build out the model I'm describing in privacy
> preserving ways, and I will argue that it will have significantly better
> security properties when compared to letting a user pick their AS.
>

I'm trying to understand how.

>
> So, let the RS dictate who it will listen to tokens from, and allow the AS
> to get its information about what those tokens are for, and when to issue
> them, from a variety of places.
>

Sorry. It's this "variety of places" that needs to be addressed as a
separation of concerns. Otherwise, we have a model that looks like the No
Fly List or a Credit Bureau where the policies and access rights of the RO
must be heavily regulated and security is a matter of "trust me" because
I've been audited by someone.

Security through zero trust architecture, as I understand it, requires
separation of concerns in the design phase, privilege minimization at the
transaction phase, as well as audit capability in the post-transaction
phase for every RS access by any end-user. I hope GNAP can describe its
role in ZTA as well as it's role in protecting privacy and human rights.

- Adrian

> From a privacy perspective, your glee over not having the RO specify the
> AS to the RS is troubling. Why would the RS care about privacy unless
> mandated in some way? (I'm assuming mandates are out of scope for GNAP :-).
>
> GNAP core must choose either or both arbitrary AS or capabilities and
> maybe explain "nervous" in a way that people can understand.
>
> - Adrian
>
>
> Assumptions. I'll focus on a very simple API from the RS perspective: a
> Scenario 1. Consider the case where a single RS manages files owned by
> Scenario 2. Now consider the case where 10 organizations each manage a