Pedro, It doesn't make sense to me that the RS would obtain the RPT... Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app. However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern. - Mike On 2015-12-09 19:37, Pedro Igor Silva wrote:

----- Original Message -----

...

From: "Mike Schwartz" To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments

UMA-tarians,

Can we discuss two ideas for enhancments:

1) UMA sans permission ticket

Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes

In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.

We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?

2) UMA without the AAT

Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?

- Mike

What about the case below ? I think it was lost because I was not able to send messages to this list ...

"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.

Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...

However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:

1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"

Any thoughts ?

...

------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org

Thanks for the reply, Mike. Personally, I also like the design of the permission ticket. Like I mentioned, it has a lot of value in certain circumstances. I also liked your proposal, it already simplifies the flow in some situations. And agree about what you said about clients and "scopes creates a tight bundling with the security infrastructure". Just to clarify, my point is basically based on use cases where a distributed application provides both a client (eg.: HTML5 + AJAX) and a RESTFul API. Where each of them is a specific deployment. In this case, once the client is issued with a OAuth2 Access Token (probably with a uma_authorization scope) it can try to access a resource on the RS, which in turn will ask the AS for a RPT based on the resource and its scopes (or even a wider range of scopes and resources). Here the AS will just evaluate the policies associated with the resources and scopes being asked and return back a RPT representing the permissions. For last, the RS check the RPT for any permission granted to the original resource and return back the RPT to the client. The client doesn't know about scopes or resources ids and don't need to access any other endpoint to obtain a RPT (making it more simple). Another scenario that I'm evaluating is to let the client obtain a RPT with all the permissions for a given user (entitlements). Currently, I'm using a standard UMA-flow (using permission tickets) to obtain this RPT. So the client only needs to obtain the RPT once, during the first interaction of the user. This is useful for permissions based on policies that don't require obligations but just evaluation based on the identity of the user or even contextual information. Regards. Pedro Igor ----- Original Message ----- From: "Mike Schwartz" To: "Pedro Igor Silva" Cc: wg-uma@kantarainitiative.org Sent: Thursday, December 10, 2015 12:23:49 AM Subject: Re: [WG-UMA] Two thoughts for UMA enhancments Pedro, It doesn't make sense to me that the RS would obtain the RPT... Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app. However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern. - Mike On 2015-12-09 19:37, Pedro Igor Silva wrote:

----- Original Message -----

...

From: "Mike Schwartz" To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments

UMA-tarians,

Can we discuss two ideas for enhancments:

1) UMA sans permission ticket

Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes

In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.

We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?

2) UMA without the AAT

Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?

- Mike

What about the case below ? I think it was lost because I was not able to send messages to this list ...

"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.

Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...

However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:

1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"

Any thoughts ?

...

------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org

IMO, OAuth2 does not provide a good support for fine-grained authorization like UMA does. Section "3.5.4 Authorization Server Response to Client on Authorization Failure" is an example of that. ----- Original Message ----- From: "Mark Dobrinic" To: "Mike Schwartz" , "Pedro Igor Silva" Cc: wg-uma@kantarainitiative.org Sent: Thursday, December 10, 2015 10:57:26 AM Subject: Re: [WG-UMA] Two thoughts for UMA enhancments Hi Mike, Don't forget the as_uri that accompanies the ticket that the RS returns to the UMA Client, in the protocol-step that you're trying to optimize. Maybe the better question is that if you assume you know which scopes to request, and the AS to make that request, why use UMA and not just plain OAuth? Mark On 10/12/15 03:23, Mike Schwartz wrote:

Pedro,

It doesn't make sense to me that the RS would obtain the RPT...

Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app.

However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern.

- Mike

On 2015-12-09 19:37, Pedro Igor Silva wrote:

...

----- Original Message -----

...

From: "Mike Schwartz" To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments

UMA-tarians,

Can we discuss two ideas for enhancments:

1) UMA sans permission ticket

Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes

In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.

We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?

2) UMA without the AAT

Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?

- Mike

What about the case below ? I think it was lost because I was not able to send messages to this list ...

"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.

Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...

However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:

1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"

Any thoughts ?

...

------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

I agree with Justin. In a person-centered real world, like in IoT or healthcare, the UMA Client knows what it needs and what's available from the UMA RS based on out-of-band means OR standards. The person-centered AS, on the other hand may be generic and hardly care. Adrian On Thursday, December 10, 2015, Justin Richer wrote:

I've actually filed an issue and am working on the ramifications of allowing the client to specify scopes in addition to the ticket. UMA paints a picture where the client doesn't know anything about the API that it's trying to access, but in the real world the client often has some idea through out of band discovery or configuration. If the client can tell the AS "these are the scopes I'm after" in addition to the ticket saying "these are the scopes recommended for that request" then the AS can make a more informed decision of which scopes to attach to the RPT.

-- Justin

On 12/10/2015 7:57 AM, Mark Dobrinic wrote:

...

Hi Mike,

Don't forget the as_uri that accompanies the ticket that the RS returns to the UMA Client, in the protocol-step that you're trying to optimize.

Maybe the better question is that if you assume you know which scopes to request, and the AS to make that request, why use UMA and not just plain OAuth?

Mark

On 10/12/15 03:23, Mike Schwartz wrote:

...

Pedro,

It doesn't make sense to me that the RS would obtain the RPT...

Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app.

However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern.

- Mike

On 2015-12-09 19:37, Pedro Igor Silva wrote:

...

----- Original Message -----

...

From: "Mike Schwartz" To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments

UMA-tarians,

Can we discuss two ideas for enhancments:

1) UMA sans permission ticket

Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes

In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.

We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?

2) UMA without the AAT

Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?

- Mike

What about the case below ? I think it was lost because I was not able to send messages to this list ...

"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.

Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...

However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:

1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"

Any thoughts ?

...

------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________

WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

UMA adds a lot of value over OAuth because it's easier to adopt to a very broad and deep ecosystem when the RS - RO interaction is separated in time from the RS - C interaction. In healthcare, this is called health information exchange and the separation allows for out-of-band RS - C discovery processes. In IoT this enables delegation where my RSs and Cs are layered like an onion around me (the layers in order: implants, wearables, mobile, router, family, cloud services). My AS is the only thing that ties these together and it needs to be as accepting of the different scopes as possible. Adrian On Thursday, December 10, 2015, Mike Schwartz wrote:

Mark,

I still think UMA adds a lot of value over OAuth2 alone! Also, my hope is that we can enable a migration plan to a better architecture.

- Mike

On 2015-12-10 06:57, Mark Dobrinic wrote:

...

Hi Mike,

Don't forget the as_uri that accompanies the ticket that the RS returns to the UMA Client, in the protocol-step that you're trying to optimize.

Maybe the better question is that if you assume you know which scopes to request, and the AS to make that request, why use UMA and not just plain OAuth?

Mark

On 10/12/15 03:23, Mike Schwartz wrote:

...

Pedro,

It doesn't make sense to me that the RS would obtain the RPT...

Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app.

However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern.

- Mike

On 2015-12-09 19:37, Pedro Igor Silva wrote:

...

----- Original Message -----

...

From: "Mike Schwartz" To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments

UMA-tarians,

Can we discuss two ideas for enhancments:

1) UMA sans permission ticket

Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes

In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.

We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?

2) UMA without the AAT

Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?

- Mike

What about the case below ? I think it was lost because I was not able to send messages to this list ...

"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.

Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...

However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:

1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"

Any thoughts ?

...

------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

--

---

Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

Yes, and the first point is touched on here: https://github.com/KantaraInitiative/wg-uma/issues/165 https://github.com/KantaraInitiative/wg-uma/issues/165 — Justin

On Dec 12, 2015, at 8:35 PM, Debbie Bucci wrote:

Is the second issue Mike raises the one Justin said he filed an issue - https://github.com/KantaraInitiative/wg-uma/issues/154 https://github.com/KantaraInitiative/wg-uma/issues/154 ?

On Thu, Dec 10, 2015 at 10:41 AM, Adrian Gropper mailto:agropper@healthurl.com> wrote: UMA adds a lot of value over OAuth because it's easier to adopt to a very broad and deep ecosystem when the RS - RO interaction is separated in time from the RS - C interaction. In healthcare, this is called health information exchange and the separation allows for out-of-band RS - C discovery processes. In IoT this enables delegation where my RSs and Cs are layered like an onion around me (the layers in order: implants, wearables, mobile, router, family, cloud services). My AS is the only thing that ties these together and it needs to be as accepting of the different scopes as possible.

Adrian

On Thursday, December 10, 2015, Mike Schwartz mailto:mike@gluu.org> wrote: Mark,

I still think UMA adds a lot of value over OAuth2 alone! Also, my hope is that we can enable a migration plan to a better architecture.

- Mike

On 2015-12-10 06:57, Mark Dobrinic wrote: Hi Mike,

Don't forget the as_uri that accompanies the ticket that the RS returns to the UMA Client, in the protocol-step that you're trying to optimize.

Maybe the better question is that if you assume you know which scopes to request, and the AS to make that request, why use UMA and not just plain OAuth?

Mark

On 10/12/15 03:23, Mike Schwartz wrote: Pedro,

It doesn't make sense to me that the RS would obtain the RPT...

Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app.

However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern.

- Mike

On 2015-12-09 19:37, Pedro Igor Silva wrote: ----- Original Message ----- From: "Mike Schwartz" > To: wg-uma@kantarainitiative.org <> Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments

UMA-tarians,

Can we discuss two ideas for enhancments:

1) UMA sans permission ticket

Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes http://gluu.co/google-scopes

In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.

We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?

2) UMA without the AAT

Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?

- Mike

What about the case below ? I think it was lost because I was not able to send messages to this list ...

"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.

Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...

However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:

1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"

Any thoughts ?

------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org <> _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <> http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

-- ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org <> _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <> http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/ http://patientprivacyrights.org/donate-2/

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve, Thanks for thinking this through, great work as usual...

Questions for you guys: What's the "coupling quotient" of the real-life use cases being considered? How often are the AS and RS in the same security domain?

For Gluu use cases, the AS and RS are usually in the same security domain.

How often does the client need to get credentials dynamically vs. pre-provisioned?

We push clients to use OIDC dynamic client registration. But sometimes they are using a form which calls the dynamic clent registration API.

How often is the client running autonomously, vs. operated by a human?

50/50. For example, in one of our current projects the mobile app talks to an initial set of API's, which themselves calls shared API's.

What are the actual use cases on the ground so far?

As I mentioned above, the main use case we are trying to solve is mobile app calling API's which call API's.

Are they such that the extensibility profile in the spec provides a starting point from which we could work outward?

Not sure.

Or do they support a serious requirement for a "client-to-AS-first" flow in the context of a _loosely coupled_ RS and AS, vs. the currently native "client-to-RS-first" flow in UMA V1.0.x that drove the design of the existing permission ticket and a sufficiently "dumb" client (no knowledge of AS location and no knowledge of scopes)?

As mentioned before, I like the permission ticket design, and I think its better than the "client-to-AS-first" pattern for a number of reasons. However... I think that in the interest of aligning with existing practices, it would be advantageous for us to undertake this work. - Mike

Hi Even, Thanks for looking this and sorry for the late reply :). Answers inline. ----- Original Message -----

From: "Eve Maler" To: "Justin Richer" Cc: "Michael Schwartz" , "wg-uma@kantarainitiative.org UMA" Sent: Monday, December 14, 2015 4:04:13 PM Subject: Re: [WG-UMA] Two thoughts for UMA enhancments

Let's explore the specific use cases that highlight limitations or impedance mismatches of current flows.

If I understand correctly, Pedro's and Mike's use cases are very similar. We've generally been calling this an API security use case. (BTW, just saying they're "NPE" use cases is ambiguous because there are other flows where a human resource owner shares with an NPE requesting party at some point, but the API security use case does have a non-person entity (organization) as an RO.)

Ok, for now on I'll refer to these use cases as API security as well. And yes, I think Mike and I are trying to address similar problems.

API security is like traditional web services security use cases, and it's a situation where a security architect would often reach for vanilla OAuth.

Agree. But we need to also consider that what you did with UMA allow us to leverage OAuth2 authorization capabilities to a new level, being more suitable in cases where you want fine-grained authorization and give to ROs more control over their resources. It should be possible to use vanilla OAuth2 and still support fine-grained authz and a plenty of UMA-like features (like the permission ticket to handle Person-To-Person authz, obligations, claims gathering, etc), but you will end up reinventing the wheel and be stuck in a proprietary solution.

Questions for you guys: What's the "coupling quotient" of the real-life use cases being considered? How often are the AS and RS in the same security domain?

I would say that AS and RS in same security domain are pretty common. Specially if you consider some enterprise use cases where you have a single AS serving different applications, where each RS may also have its own and single client. For instance, a vanilla (HTML5 + AngularJS) + RESTFul design. Here we don't have third-party clients consuming RS's API. In these cases, the client does not need to know the scopes, but just the API. Is up to the RS to discover the scopes and enforce policies based on the relaying party or/and the client accessing the API. For instance: 1) Client (on behalf of an user) tries to access a resource 2) RS knows both ID and scope(s) related with the request and asks the AS for a RPT with the required permissions. 3) AS evaluates the policies based on the authorization request from the RS and issues a RPT. 4) RS enforces the authorization decision from AS and gives back the RPT to the client. See, the client is pretty much dumb. It does not know about resource ids or scopes. Just like what the permission ticket does. We are just making client's more simple to implement and avoid additional requests (one to send the ticket to AS and another that sends the RPT back to the RS). It is worthy to mention that UMA already supports the flow above. I can just handle the permission ticket flow within the RS and return back the RPT to the client (or any other result from the AS). But, am I violating any rule by doing this ? The same thing applies if I want to obtain a RPT with everything an user/client is entitled to do (entitlements) once. I can just configure the RS to build a permission ticket asking for every single resource/scopes during a first interaction.

How often does the client need to get credentials dynamically vs. pre-provisioned? (Note that OAuth ecosystems today are tightly coupled by nature: The AS/RS is in one domain, and clients are statically provisioned with credentials, often to be sure that they can execute terms of service.) How often is the client running autonomously, vs. operated by a human?

Right now, I'm more focused with pre-provisioned clients. Although they can also register themselves using OpenID Connect Dynamic Client Registration. I'm also focused on clients operated by a human. Although I think we can handle autonomous clients using offline tokens to evaluate authorization policies on the AS and enforce them on the RS.

The API security use case overall would normally already be signed up to a smart client that knows the API, knows the API's scopes, knows the AS location, and wants to get down to making API calls. In a person-to-person delegation use case, Alice is likely to give Bob first-order consideration -- he'll get what scopes he'll get, and he'll like it! -- in configuring policy constraints.* But in autonomous-client API security use cases, I suspect AliceCorp needs the client to be more, well, autonomous in wanting to request every scope it can handle, and perhaps in some human-operated client variants (AliceCorp-to-Bob) of the API security use case as well (asking up-front for everything it can handle).

So, based on this analysis, some thoughts and key questions.

Thoughts: As I had noted to Pedro in private email back in October, there is an “ extensibility profile ” in the UMA Core spec to allow lots of optimizations when the RS and AS are tightly coupled. This would enable more efficient RS-AS communication regarding resource set registration, permission registration, and token introspection — it could all be “implicit” because the same hunk of software is on both sides. However, some tokens would still have to be produced for client consumption because it may still be a third-party hunk of software.

+1. I just want to make sure I'm not violating the rules.

Key questions: What are the actual use cases on the ground so far? Are they such that the extensibility profile in the spec provides a starting point from which we could work outward? Or do they support a serious requirement for a "client-to-AS-first" flow in the context of a loosely coupled RS and AS, vs. the currently native "client-to-RS-first" flow in UMA V1.0.x that drove the design of the existing permission ticket and a sufficiently "dumb" client (no knowledge of AS location and no knowledge of scopes)?

My use cases are all based on the currently native "client-to-RS-first". I think "client-to-AS-first" will kill the benefits brought by UMA, specially from a client perspective. Btw, I like the permission ticket (and the whole idea behind it) and, like I mentioned before, it has a lot of value. Specially for person-to-person delegation use cases. I think my question for all that should be: Am I violating UMA's rules if I change the flow under certain circumstances ? Or am I forced to always use a permission ticket as defined by the specs ? Thanks again for your time !

Eve

*UMA still allows for Alice's policy to constrain clients, of course (because policy doesn't appear on the wire in UMA), and any client involved in an Alice-to-Bob use case that can't handle scope x will never attempt an API call using scope x anyway...

Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Sat, Dec 12, 2015 at 5:45 PM, Justin Richer < jricher@mit.edu > wrote:

Yes, and the first point is touched on here:

https://github.com/KantaraInitiative/wg-uma/issues/165

— Justin

On Dec 12, 2015, at 8:35 PM, Debbie Bucci < debbucci@gmail.com > wrote:

Is the second issue Mike raises the one Justin said he filed an issue - https://github.com/KantaraInitiative/wg-uma/issues/154 ?

On Thu, Dec 10, 2015 at 10:41 AM, Adrian Gropper < agropper@healthurl.com > wrote:

UMA adds a lot of value over OAuth because it's easier to adopt to a very broad and deep ecosystem when the RS - RO interaction is separated in time from the RS - C interaction. In healthcare, this is called health information exchange and the separation allows for out-of-band RS - C discovery processes. In IoT this enables delegation where my RSs and Cs are layered like an onion around me (the layers in order: implants, wearables, mobile, router, family, cloud services). My AS is the only thing that ties these together and it needs to be as accepting of the different scopes as possible.

Adrian

On Thursday, December 10, 2015, Mike Schwartz < mike@gluu.org > wrote:

Mark,

I still think UMA adds a lot of value over OAuth2 alone! Also, my hope is that we can enable a migration plan to a better architecture.

- Mike

On 2015-12-10 06:57, Mark Dobrinic wrote:

Hi Mike,

Don't forget the as_uri that accompanies the ticket that the RS returns to the UMA Client, in the protocol-step that you're trying to optimize.

Maybe the better question is that if you assume you know which scopes to request, and the AS to make that request, why use UMA and not just plain OAuth?

Mark

On 10/12/15 03:23, Mike Schwartz wrote:

Pedro,

It doesn't make sense to me that the RS would obtain the RPT...

Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app.

However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern.

- Mike

On 2015-12-09 19:37, Pedro Igor Silva wrote:

----- Original Message -----

From: "Mike Schwartz" < mike@gluu.org > To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments

UMA-tarians,

Can we discuss two ideas for enhancments:

1) UMA sans permission ticket

Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes

In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.

We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?

2) UMA without the AAT

Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?

- Mike

What about the case below ? I think it was lost because I was not able to send messages to this list ...

"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.

Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...

However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:

1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"

Any thoughts ?

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Thanks for the reply! No worries at all on timing, as everyone's a volunteer here (and it took me long enough to reply anyway). (And I get "Even" a lot. :-) Below... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Wed, Dec 16, 2015 at 10:50 PM, Pedro Igor Silva wrote:

Hi Even,

Thanks for looking this and sorry for the late reply :). Answers inline.

----- Original Message -----

...

From: "Eve Maler" To: "Justin Richer" Cc: "Michael Schwartz" , "wg-uma@kantarainitiative.org UMA" Sent: Monday, December 14, 2015 4:04:13 PM Subject: Re: [WG-UMA] Two thoughts for UMA enhancments

Let's explore the specific use cases that highlight limitations or impedance mismatches of current flows.

If I understand correctly, Pedro's and Mike's use cases are very similar. We've generally been calling this an API security use case. (BTW, just saying they're "NPE" use cases is ambiguous because there are other flows where a human resource owner shares with an NPE requesting party at some point, but the API security use case does have a non-person entity (organization) as an RO.)

Ok, for now on I'll refer to these use cases as API security as well. And yes, I think Mike and I are trying to address similar problems.

In Thursday's call/notes, I tried some terminology to bifurcate two sub-use cases: plain "API security" where the AS and RS reside in the same domain, and "federated authorization" where it can be useful to decouple the AS and RS. I'm seeing the latter in a bunch of cases, e.g. when it comes to RS's that are partners (SaaS or otherwise) vs. internal -- analogously to "federated authentication".

...

API security is like traditional web services security use cases, and

it's a

...

situation where a security architect would often reach for vanilla OAuth.

Agree. But we need to also consider that what you did with UMA allow us to leverage OAuth2 authorization capabilities to a new level, being more suitable in cases where you want fine-grained authorization and give to ROs more control over their resources.

Yep. A person as unambiguous RO is a new step.

It should be possible to use vanilla OAuth2 and still support fine-grained authz and a plenty of UMA-like features (like the permission ticket to handle Person-To-Person authz, obligations, claims gathering, etc), but you will end up reinventing the wheel and be stuck in a proprietary solution.

Indeed, the UMA flows so far have a single (relatively simple) pattern with complex effect. This is where I was sort of going with the ideas that Alice has direct say over Bob's access, and that we have to satisfy a requirement for AS-RS loose coupling; these are the big reasons that the a permission ticket flow popped out of the design process. OAuth, having only one "user" and colocated AS and RS, didn't have (or even think of?) that.

...

Questions for you guys: What's the "coupling quotient" of the real-life

use

...

cases being considered? How often are the AS and RS in the same security domain?

I would say that AS and RS in same security domain are pretty common. Specially if you consider some enterprise use cases where you have a single AS serving different applications, where each RS may also have its own and single client. For instance, a vanilla (HTML5 + AngularJS) + RESTFul design. Here we don't have third-party clients consuming RS's API.

Meaning that RS=client (a la Google Apps, where the only app that operates on a GDoc file is the GDoc app)? I'm guessing not, if you'd prefer for the client to be as "dumb" as possible. (But note that there's an extensibility profile https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#alt-resour... for RS = client too.)

In these cases, the client does not need to know the scopes, but just the API. Is up to the RS to discover the scopes and enforce policies based on the relaying party or/and the client accessing the API. For instance:

1) Client (on behalf of an user) tries to access a resource 2) RS knows both ID and scope(s) related with the request and asks the AS for a RPT with the required permissions. 3) AS evaluates the policies based on the authorization request from the RS and issues a RPT. 4) RS enforces the authorization decision from AS and gives back the RPT to the client.

See, the client is pretty much dumb. It does not know about resource ids or scopes. Just like what the permission ticket does. We are just making client's more simple to implement and avoid additional requests (one to send the ticket to AS and another that sends the RPT back to the RS).

Right, this sounds like straight UMA, with a client that can remain dumb wrt scopes but of course needs to know the API. Of course, the RS has the capacity to own/invent/control the scopes, not "just" discover them, because the scopes are essentially a part of the API's design. It is worthy to mention that UMA already supports the flow above. I can

just handle the permission ticket flow within the RS and return back the RPT to the client (or any other result from the AS). But, am I violating any rule by doing this ?

The flow looks sort of similar to today's UMA, but it's not totally accurate for off-the-shelf UMA. If you're suggesting changes in order to remove the permission ticket, making the RS do all that work to get the RPT on behalf of the client (step 2), ending with it giving the resulting RPT to the client along with giving access (step 4), then I have some questions... To be super-clear, here's an annotated version of your flow with the delta from UMA V1.0.1: 1) Client (on behalf of an user) tries to access a resource (that's the same as now -- Core Sec 3.1.1 https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#without-rp... ) 2) RS knows both ID and scope(s) related with the request and asks the AS for a RPT with the required permissions. (today, Core Sec 3.2 https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#register-p..., the RS would register a requested permission: a resource set by ID, with as many scopes as desired; we've also floated an extension spec that allows the RS to register multiple resource sets, each with as many scopes as desired) 3) AS evaluates the policies based on the authorization request from the RS and issues a RPT. (today that only happens after the RS gives the permission ticket to the client (Core Sec 3.3.1 https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#permission...) and when the client -- not the RS -- shows up at the RPT endpoint with the permission ticket (Core Sec 3.5.1 https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#rfc.sectio... )) 4) RS enforces the authorization decision from AS and gives back the RPT to the client. (today that only happens when the client retries access with the RPT -- Core Sec 3.1.2 https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#with-rpt ) Why bother giving the RPT to the client if the RS could just give access directly? The whole thing would then look really close to an XACML flow, including the PEP/RS (vs. the client, what XACML would call the "application") making the request of the PDP/AS. Another similarity would be AS-RS tight coupling. In these circumstances, it also seems like scopes would be "internal" to the AS-RS, and you could move to getting a simple Permit/Deny answer from the AS instead of the permissions data structure, which could make the RS even simpler than it is now. If there's no RPT, though, then it wouldn't be around to collect/cache a bunch of decisions for later use by the client, but maybe that makes sense to me since the client would never go straight to the AS itself. However, then you could stop using UMA and start using XACML. :-) In cases where the entities do need loose coupling or other UMA/OAuth benefits (scale, dynamic client registration, lighter weight, RESTful, RS wanting to use its right to perform extra authorization against the client and requesting party...), can we assume that this flow wouldn't apply? Is the value of removing the ticket (and possibly change these other things for full optimization) for this glued-together API security flow valuable enough to pursue in UMA vs. sticking with the usual flow? How much optimization can really be achieved, vs. getting other marginal benefits out of using the flow that's already there (if you already are getting benefit out of "dumb" clients, scopes, etc.)?

The same thing applies if I want to obtain a RPT with everything an user/client is entitled to do (entitlements) once. I can just configure the RS to build a permission ticket asking for every single resource/scopes during a first interaction.

This is a relatively common thing to do in other use cases outside of API security as well.

...

How often does the client need to get credentials dynamically vs. pre-provisioned? (Note that OAuth ecosystems today are tightly coupled by nature: The AS/RS is in one domain, and clients are statically provisioned with credentials, often to be sure that they can execute terms of service.) How often is the client running autonomously, vs. operated by a human?

Right now, I'm more focused with pre-provisioned clients. Although they can also register themselves using OpenID Connect Dynamic Client Registration.

I'm also focused on clients operated by a human. Although I think we can handle autonomous clients using offline tokens to evaluate authorization policies on the AS and enforce them on the RS.

...

The API security use case overall would normally already be signed up to

...

smart client that knows the API, knows the API's scopes, knows the AS location, and wants to get down to making API calls. In a

...

delegation use case, Alice is likely to give Bob first-order consideration -- he'll get what scopes he'll get, and he'll like it! -- in configuring policy constraints.* But in autonomous-client API security use cases, I suspect AliceCorp needs the client to be more, well, autonomous in wanting to request every scope it can handle, and perhaps in some human-operated client variants (AliceCorp-to-Bob) of the API security use case as well (asking up-front for everything it can handle).

So, based on this analysis, some thoughts and key questions.

Thoughts: As I had noted to Pedro in private email back in October,

a person-to-person there is

...

an “ extensibility profile ” in the UMA Core spec to allow lots of optimizations when the RS and AS are tightly coupled. This would enable more efficient RS-AS communication regarding resource set registration, permission registration, and token introspection — it could all be “implicit” because the same hunk of software is on both sides. However, some tokens would still have to be produced for client consumption because it may still be a third-party hunk of software.

+1. I just want to make sure I'm not violating the rules.

...

Key questions: What are the actual use cases on the ground so far? Are

they

...

such that the extensibility profile in the spec provides a starting point from which we could work outward? Or do they support a serious requirement for a "client-to-AS-first" flow in the context of a loosely coupled RS and AS, vs. the currently native "client-to-RS-first" flow in UMA V1.0.x that drove the design of the existing permission ticket and a sufficiently "dumb" client (no knowledge of AS location and no knowledge of scopes)?

My use cases are all based on the currently native "client-to-RS-first". I think "client-to-AS-first" will kill the benefits brought by UMA, specially from a client perspective.

Btw, I like the permission ticket (and the whole idea behind it) and, like I mentioned before, it has a lot of value. Specially for person-to-person delegation use cases.

I think my question for all that should be: Am I violating UMA's rules if I change the flow under certain circumstances ? Or am I forced to always use a permission ticket as defined by the specs ?

Thanks for weighing in! I would love to get your thoughts on my questions above. To summarize my observations, your proposed flow would be more direct, but also doesn't "go all the way" in optimizing the direction you're heading. In your current thinking about your use case, is it more important to optimize fully (get more "XACML-ish"), or optimize a little (roughly your current midway point), or use UMA's other benefits fully (keep something like the current ticket flow)?