Ensure resource server only outsources protection for the RO's legitimate resources

[xmlgrrl]

Alan Karp reported an issue recently having to do with RS implementors' likelihood of misunderstanding or mishandling a request by an RO to register a resource for protection. The concern is that the RS might readily register resource sets that the RO does not have rights to control access to. Alan's recommendation: "It is the responsibility of the resource server to guarantee that the person telling the resource server to protect a resource has the specified rights to the resource." He notes: If that check isn't made by the resource server, anyone with an account at the resource server can gain access to a resource solely by asking the resource be registered with a policy that would result in the authorization manager granting that user access.

Various implications for our docs:

• Add nonnormative wording as suggested by Alan?
• Consider specific implications of "downstream" vs. "originating" RO instructions for protecting resources (without getting into the DRM argument), to enable Bob to share, say, "read" access to some resource set with further-downstream requesting parties if a) Alice let him have that access to her photo album and b) he didn't promise he wouldn't through a claim?
• Consider adding or revising a binding obligation on the RS around this?

[xmlgrrl]

From UMA telecon 2013-06-13: One scenario is that Bob views Alice's photo without having "copied" it into his own area where he has full RO rights. Another is that Bob copies the photo, thereby gaining full (potentially inappropriate!) RO rights. If Bob offers a claim that means he agrees to constrain his own downstream sharing, then this puts the second solution firmly into the realm of our binding obligations. For example, Eve goes to Flickr and logs in, and finds George's public photo of a flower (http://www.flickr.com/photos/gffphotos/9014879557/lightbox/). Flickr shouldn't enable Eve to set CopMonkey resource protection over George's photo. George cautions against being too prescriptive; there are circumstances where Alice might want to award Bob something like "admin" or "access management" permissions, so that even if Bob was the initial resource owner/authorizing party, he might be a downstream one. Andrew asks: How is "protectable resource" as in Sec 2.3.1 of Binding Obs (http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor12) defined? It's not, yet!

Does this really need to be specified, or is this simply the definition of what a "resource server" is? It's responsible for mapping resources to their rightful owners and controllers. UMA just lets it outsource protection (the mapping of access control rules to access actions). Maciej points to Puma's conceptual diagram (http://smartjisc.files.wordpress.com/2012/04/erd.png?w=595) that demonstrates the essentiality of what web apps have to do in terms of mapping protectable resources to logged-in owners. But Andrew's point about "protectable resources" not being defined is a good one. OAuth's definition of "resource owner" (which we borrow from, in part) is pretty good, but OAuth doesn't define "protected resource". What we may need is a definition for the resources that are capable of/candidates for being protected by a legitimate resource owner. The PAT that the resource server chooses to make the resource set registration call to the authorization server is exactly the mapping that the RS has chosen to make to a particular resource owner.

What we haven't decided is whether this is so obvious as to not require technical or binding obs wording, or whether we should add wording to clarify.

[xmlgrrl]

UMA 2.0 Core (rev 10) talks about resource server responsibilities in language such as the following:

https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-10.html#resource-scope-interpretation

"The resource server MAY register for protection a single resource that, from its perspective, has multiple parts, or has dynamic elements such as the capacity for querying or filtering, or otherwise has internal complexity. The resource server alone is responsible for maintaining any required mappings between internal representations and the resource identifiers and scopes known to the authorization server. Because access attempts on resources by clients are resource identifier-unaware, the process of making a permission request may also require interpretation by the resource server in order to establish a suitable resource identifier, resource owner, and authorization server."

Statements in other sections talk about about needing to map to the relevant resource identifier, resource owner, and authorization server before (say) requesting permissions on behalf of the client. Can we assume this is sufficient?