Consider adding optional location URI property to resource set description

[xmlgrrl]

With a property like this, the RS can inform the AS of not just the abstract properties of a resource set, but a specific property as well: its location, which can help the AS in term inform others that want to know. This could be useful not just for an UMA AS, but also for an OpenID Connect OP in the use case identified in the RSR spec introduction, for feeding a distributed claims (or even aggregated claims) mechanism.

Nat and I discussed this while at IIW this week. It would be an extremely lightweight way to help solve an important portion of the personal discovery service challenge discussed in issue #20, as well as the resource "baskets" or "bundles" notion discussed in issue #31, because the application hosting the AS could also be an RS with a special "singular" UMA-protected resource set that consists of a set of pointers, OpenID Connect distributed claims-style (http://openid.net/specs/openid-connect-core-1_0.html#DistributedExample), to a variety of other OAuth-protected resource sets (possibly at multiple resource servers).

[mmachulak]

Adding a location URI is a good idea. Cloud Identity already supports in its UMA implementations.

[andihindle]

What do we mean here by 'location'? URI? Or physical?

[xmlgrrl]

The intent is URI. This way, the "real" resource's web location can be discovered by a client that successfully gains authorized access to a "pointer" resource. The way OpenID Connect's mechanism works, a distributed claim is a structure that contains a location URI (a pointer) and an access token for getting into that location.

[mdobrinic]

I would say that the registration of a Location URI property is a very good idea, but it is not something necessary for core Resource Registration, as in: shouldn't this be an extension to it? The Resource Registration spec allows for extensions...

Also, when specifying Location URI, it might be better suited to describe what that actually means in a Resource Discovery context; which is different from Resource Registration.

What do you think?

[xmlgrrl]

After much discussion on the list and in meetings, concluding in ad hoc (quorate) UMA telecon 2014-11-15, we agreed to add resource_uri to RSR, and not to concern ourselves at the moment with methods of further solving protection questions related to issue #31 and #20. We agreed not to "rush to a design for how "distributed (UMA-)protected resources" should be solved right now. If we put the resource_uri piece in, at least the first half of the data structure can be populated; the second half of the data structure that equates to the OIDC distributed claims "access token" would still need to be figured out."

This will be implemented in RSR rev 05.