I've been thinking about this issue, and I'm not sure I understand the use
case - can you explain a bit please Mike?
The main use that I came up with was the ability to be able to manage
policy for "all my documents" as well as, or instead of, just "my resume".
However, it seems to me that that ability is much better managed internally
by the RS rather than exposing it to the AS, by exposing a resource-group
resource, or at the AS by allowing the RO to make arbitrary groupings
between registered resources.
Cheers,
James
On 22 January 2017 at 23:21, Eve Maler
In this message, I want to share the results of the ad hoc discussion we had after Thursday's formal call ended. *No set of options or proposal in this one*, because I think we need to discuss it more. Please read and weigh in before the next meeting!
Here's the relevant part of the notes http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-19 :
==== *270 https://github.com/KantaraInitiative/wg-uma/issues/270: Resource Registration Document: 'uri' should be an array / examples:* Gluu had actually assumed this was already an array, and implemented it that way! And wildcards would be really handy. Especially with the ability to request permissions (get permission tickets) "in bulk" now, registering resources seems to be an obvious parallel task that should be done in bulk. Note that there are two theories about *when* to register resources: eager (when they are created at the RS/host), and lazy (when the resource owner wants to share them). The latter puts resource registration very close to the time of permission requesting. So they would seem to want to be aligned. (Also note that our current design of requesting multiple permissions (resource IDs) has us using an array, but requesting a single permission (resource ID) uses an object! Other instances of ability to "do multiple things with one thing as an edge case" in the spec, as designed natively in V1.0, are all done as arrays. ====
There are a couple of things that could potentially be going on here; we could take action on either of them, or both.
First, Mike has pointed out that the optional "uri" field a) has been given short shrift (it's not in any examples and should be, because developers often only implement what's in examples) and b) would be valuable if it were made more powerful, to allow the RS to associate multiple URIs with a single resource ID through registration. Conveying this information allows the AS to take on the web access management (WAM) job of managing a set of protected URIs, and even a wildcarded set (as shown at the linked issue with an asterisk), as mapped to a single logical resource ID at the RS. The other cool thing the AS can do with the "uri" info is enable discovery of resource locations.
Options around this might include something like "Consider changing/extending the 'uri' property structure in the resource description document."
Second, what I originally thought when Mike brought this up to me was that the RS might want to literally *operate on multiple resources at one time* when doing CRUD operations at the RReg API. I actually keep confusing the two ideas (sorry about that), , which is why the meeting notes above read as they do. So, for example, if the client approaches the RS to attempt access to some resource, and the RS (using "lazy" resource registration and a "generous" permission request regime) needs to register the three resources that it wants to then request on the client's behalf, it has to do three *inefficient* Create requests in a row to the resource registration endpoint before doing one *efficient* call to the permission endpoint.
Options around this might include something like "Consider changing the RReg API calls to allow creating/reading/updating/deleting multiple resources at once." (Listing already happens on a whole set.)
====
Thoughts, everyone?
*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma