January 2017 - WG-UMA - mailman.kantarainitiative.org

Default-deny
by James Phillpotts 01 Feb '17

01 Feb '17

Hi all, Thanks for the reminder to send this email Eve! ;) The paragraph in question is: The authorization server MUST use a default-deny authorization assessment model in adding permissions to RPTs, that is, "everything that is not expressly allowed is forbidden" for resources for which resource servers have requested access permission on behalf of clients. Exercise caution in implementing default-deny because corner cases can inadvertently result in default-permit behavior. For example, it is insufficient simply to assume that all resources have some non-zero set of claims required for access, and then accept an empty set of supplied claims as sufficient for access. I'm not convinced that this paragraph is really very useful, but that may be because it isn't clear at what level the 'deny' is relating to in this context - is it on a per-resource, per-scope, or an RPT level? If per-resource, I think this is a reasonable thing to express, but I'm not sure the paragraph does a particularly good job of it. If per-scope, does this only apply to additional scopes requested by the client? If RPT, then I don't think the idea is correct, as the RPT shouldn't be denied based on the outcome of a particular policy for a particular resource. On one of the calls I thought someone had mentioned that the RPT should only be granted if all of the scopes requested in the permission ticket were able to be granted, but I think it should be perfectly reasonable to grant a subset - e.g. if ticket requests view, edit for resource A and view for resource B but all that can be granted is view for A, then that is a perfectly reasonable response? This was partly triggered by Mike's suggestion of patterned URIs, where I was thinking about the RS wants *either* view on A, view on B or view on C, because it knows that the actual requested URL is covered by all 3 of those registered resource sets (although as per other email, I wouldn't like that to be a pattern). Sorry if this is slightly rambling. Cheers, James

4 16

Issue 260 Cascading authorization servers
by Kathleen Connor 30 Jan '17

30 Jan '17

Hi Everyone, Mohammad intended to response to the minutes from UMA telecon 2017-01-19 about Issue 260 https://github.com/KantaraInitiative/wg-uma/issues/260 but apparently, his message was not published [shown below]. So I am resending since I agree with him that issues raised in the WG seem to be based on policy that the example use of Cascading OAuth that Mohammad presented exemplified. Other policies would make very different rules about which AS is "on first". I know that there's no time until late in February to have further discussions on our request that UMA WG consider this proposed profile. I've requested time at the next available agenda slot. Thank you for this first round of discussion. -K * Putting the RS in charge of orchestrating the cascaded authorization flow will involve the RS in making authorization decisions and handling authorization logic, including policy processing. The RS will have to decide what ASes need to be consulted and how to combine their decisions. Such arbitration must inevitably be based on some policy rules and this will end up putting the burden of authorization and policy processing on the RS, which is contrary to separation of concerns, and also defeats one of the primary purposes of UMA, which as I understand, is to take the burden of policy processing off the shoulders of the RS. In other words, let's draw a rectangle around that component in the RS which is in charge of this orchestration and handling these authorization decisions and call it the "Downstream AS". * The question of who controls each AS is a matter of policy and orthogonal to this design. The downstream AS is the eventual arbiter that should decide for any given access request, what ASes must be consulted and how their decisions must be reconciled and combined. Moreover, in the process of combining introspections from the upstream ASes, the downstream AS has the authority augment/abridge the scope/permission set as well. This provides the capability to enforce various kinds of policy combining strategies. For instance, in your example of the so called "data blocking", if the organizational policies override patient consent, then the downstream AS should be configured with the combining policy that combines the decisions that way. Likewise, if the patient consent overrides, the respective combining policy can be stated at the downstream AS. Other combining logics (e.g. simple AND/OR, majority vote, and more sophisticated combining logic with respect to scopes/permissions) can be implemented in a similar vein (*). In all of these cases, the design is the same and thus is agnostic to the particular policy/configuration -be it authorization policy, or decision combining policy. * I think leaving the cascaded authorization logic to out-of-band protocols, is outside the scope of this discussion and somehow beside the point. We are in a standard WG because to standardize the flow where multiple policy authorities host their own respective ASes which is a generalization of the basic UMA use-case. Of course, this, or for that matter, even the main authorization use-case of UMA, can all be considered out of band but that's not the point. Regards, Mohammad (*) To clarify a technical detail, I'm aware that if any of the upstream RPTs refuse to issue the RPT altogether (a 403) then the flow halts and this means a disjunctive (OR) combining can't take place. However, this can be fixed by having the upstream ASes issue an RPT with an empty scope/permission set when they intend to deny an access so that the flow can move on. *260 <https://github.com/KantaraInitiative/wg-uma/issues/260>: Cascading authorization servers:* Recall that the use case (from the FHIR world) is that the RS has "edge authorization" it needs to perform, which it has ensconced in enterprise policies in its own authorization server. This is a way to have the "Adrian clause" reified in RPTs, and the client/RqP meet multiple sets of policy conditions, all the way. This connects to the shoebox question if you can get the RS to report what they've done. In the swimlane, the "downstream AS" is Alice's and the "upstream AS" (and any further upstream ones) belongs to the RS. So, in a way, this has positives and negatives: the incentives change because on the one hand an RS gets a lot more formal and dynamic control of liability, but on the other, it can control much more strongly what Alice gets to share, possibly enabling "data blocking" (a phrase from the health world). This has been done as an extension already, so it could remain an extension for now. It has "set math" implications, because it introduces another set. Eve's observations about the flow: - AS needs to know about the other AS because it's a client of the permission request endpoint - Client needs credentials for the upstream AS(s) too - Client needs to keep an "AS stack" and to hold multiple RPTs for "that resource" (whatever that means to the client) - (George added:) There's new set math that each downstream AS has to calculate Kathleen Connor VHA Security Architecture - Framework Engineering (Edmond Scientific Company) HL7 Security and Financial Management Cochair Office - 360 357 3536 [Primary] Cell - 360 480 7599

1 0

UMA RequestedScopes Venn representation
by Domenico Catalano 26 Jan '17

26 Jan '17

Hi, Here is a Venn representation of the RequestedScopes set, based on the following formula: RequestedScopes = union ( intersection (ClientRequested, ClientRegistered), PermissionTicket). RequestedScopes = C ∪ (A ∩ B) = (C ∪ A) ∩ (C ∪ B) I hope it’s accurate! Thanks Domenico

2 1

Draft minutes of UMA telecon 2017-01-26
by Eve Maler 26 Jan '17

26 Jan '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-26 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-01-19 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-19>: APPROVED. Logistics - Idea: Vote on WG draft on Feb 9 and open it up to a "last call" period for about four weeks? We need burn-in/beta time, it seems - No meeting Feb 16 because of RSAC We like the idea of a Last Call period to shake out things. Several of us are doing some incremental implementation work. We can never make people look, but we can do our best to draw attention. So our new plan of record is to publish a WG draft by Feb 9. UMA V2.0 work *266 <https://github.com/KantaraInitiative/wg-uma/issues/266>: Set math:* Typo: "RequestedScopes contains view, print, and print" should obviously be "RequestedScopes contains view, print, and download". The list discussion, netted out, is: Should the AS be able to issue fewer scopes than the RS put into the permission ticket, or not? And if so, should it be able to do so on a per-resource basis? Since OAuth happily tells the client what scopes were issued, why can't we do the same? Can we do this and not share the resource IDs? We have seen the resource IDs as privacy-sensitive personal information. It's unfortunate that the OAuth architecture overall hasn't yet had a way to identify specific resources. Eve had put this language in rev 13: "The client attempts what the resource server interprets as view access to rsid_1. The resource server chooses to request view and print scopes on its behalf". (Should be "...to request view and print scopes for rsid_1...") This is hinting at what the RS is authoritative for: interpretation of the API call and choices about the extent of the permission request. This needs to be discussed in a proper place in the spec. All this probably belongs in Sec 1.3 somewhere. The client should be discussed here too! George proposes, and James supports, that *PermissionTicket* scopes MUST be met per resource, which ties the AS's hands in terms of what it rejects and incentivizes the RS in terms of requesting "too much". Park this for a moment. This would change the Venn diagram, and the decision on the issue below would change the outcome of this discussion. --- James proposes having the AS report rejected scopes in the token introspection object so that the RS can decide if it wants to keep trying (that is, requesting permissions on behalf of the client again and again). But what if the RS is tired of dealing with looping? We do have a clause that says "The recipient of each request message SHOULD respond unless it detects a security concern, such as a suspected denial of service attack that can be mitigated by rate limiting." Cigdem says: "I agree with the second option. If RS records what permissions it asked for the client, and then checks it against received RPT, it can diff what is denied. (And the missing permissions in the RPT was a result of RS being permissive and AS granting only resources that fully match RS’s permission, RS can try again)." A more informative token introspection object allows the RS to craft a permission request that is responsive to what the requesting party/client is actually seeking access to, while adhering to minimum disclosure principles if it wants to. Could we still have the concept of the client including a previous RPT on its request? It appears so, because all the scopes in such an RPT are associated with resources. Because the client doesn't know how its tokens relate to its successful accesses, its only choice is to try and send all of its previous RPTs. But it would only have one because it would have had to invalidate each last one. The idea is that the AS would provide the last-issued ticket, broken out with the state it had kept associated with it. AI: James: Send concrete example of how to solve this problem. *Other:* The "easy issues" will be resolved as noted: - 264 <https://github.com/KantaraInitiative/wg-uma/issues/264>: Authentication-related error details (will close with only editorial/example text) - Shoebox: Will remove V2.0 label from 246 <https://github.com/KantaraInitiative/wg-uma/issues/246>, 245 <https://github.com/KantaraInitiative/wg-uma/issues/245>, 224 <https://github.com/KantaraInitiative/wg-uma/issues/224>, 63 <https://github.com/KantaraInitiative/wg-uma/issues/63>, 24 <https://github.com/KantaraInitiative/wg-uma/issues/24> and make them a parallel activity *Spec instructions:* - Fix typo shown above - Fix permission request language shown above - "Easy issues" Attendees As of 19 Jan 2017 (post-meeting), quorum is 5 of 8. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem, Sarah) 1. Domenico 2. Sal 3. Maciej 4. Eve 5. Mike 6. Cigdem 7. Sarah Non-voting participants: - James - George - Justin - Ishan - Kathleen - Jin Regrets: - JohnW - Andi *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

276: Scope string: "friendly name" and "identifier" the same: do they need to be split?
by Eve Maler 25 Jan '17

25 Jan '17

This message discusses an issue not brought up yet in our meetings. Please read and weigh in (even with a +1, if you agree...) by *Tuesday* if possible!) 276 <https://github.com/KantaraInitiative/wg-uma/issues/276>: Scope string: "friendly name" and "identifier" the same: do they need to be split? ==== In the ad hoc discussion post-UMA telecon 2017-01-19 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-19>, we had a discussion that I don't think I captured in the notes: While the "name" property for a scope description defines itself (Sec 2.1.1 <https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-04.html#ac…> in RReg 2.0 rev 04) as being a human-readable string, that leaves it without a separate (if desired) machine-readable scope string. In implementations it's been treated primarily as the latter and displayed also as the former, so effectively serving as both. In the case of resources, these two concepts are naturally split because the AS gives back an identifier. ==== Note that the current "name" property is OPTIONAL, and that this is part of the scope description document that the AS resolves if it's gotten a URI from the RS (keep in mind the email sent earlier today about issue 269!). In this case, the URI could simply have served as the machine-readable name. Here are the options I can think of. (Let me know if I missed any.) 1. Do nothing. 2. Add a new bit of description to the existing "name" property to say that it's meant to serve as the machine-readable name as well. 3. Add a "scope_id" property of some kind. 4. Change the "name" property to have the machine-readable name semantic, and add a "friendly_name" property of some kind. ==== Here is my proposal: *Option 1*. Rationale: - I believe it's correct to interpret the URI as the "scope identifier". If we need to say so in the spec, then we can. - The "name" property for a scope has, and should have, the same role as the "name" property for a resource. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 3

Agenda for UMA telecon 2017-01-26 (90 minutes)
by Eve Maler 25 Jan '17

25 Jan '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-26 Date and Time - *Thursdays,* *special meeting times through Feb 9: 8:30-10am PT* - Skype: +99051000000481 / US +1-805-309-2350 / international lines <https://www.turbobridge.com/join.html> / web calling interface <https://panel.turbobridge.com/webcall/> / code 1782540 - Screen sharing: http://join.me/findthomas - NOTE: do not use the join.me dial-in line - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2017-01-19 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-19> - Logistics: - Idea: Vote on WG draft on Feb 9 and open it up to a "last call" period for about four weeks? We need burn-in/beta time, it seems - No meeting Feb 16 because of RSAC - UMA V2.0 work - 2016 roadmap <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> / GitHub issues for V2.0 <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> (all issues to be kept here for the duration!) / dynamic swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> - Core is up to 13 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-13.html> (updated) and RReg is up to 05 <http://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-05.html> (updated) - Core: mostly authorization assessment <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-13.html#authorizatio…> and editorial changes; "claim token" also now defined (closing #256) - RReg: #276 trial text for the scope property - 266 <https://github.com/KantaraInitiative/wg-uma/issues/266>: Set math - Critique new wording and spec structure (Sec 1.4.2 / Sec 3.6.5) - What should be done about previous RPTs on requests – if they're allowed, why, what does the AS do in return, and what does the client do with its various RPTs? - How (and where in the spec) should the RS document its permission request practices so the client has an idea what's in its RPTs? - Are our "notes" for default-deny and everything else as they should be? - Can we close the issue after this? - Discuss and clear the RReg issues - 269 <https://github.com/KantaraInitiative/wg-uma/issues/269>, 270 <https://github.com/KantaraInitiative/wg-uma/issues/270>, 271 <https://github.com/KantaraInitiative/wg-uma/issues/271>, 272 <https://github.com/KantaraInitiative/wg-uma/issues/272>, 273 <https://github.com/KantaraInitiative/wg-uma/issues/273>, 276 <https://github.com/KantaraInitiative/wg-uma/issues/276>, 277 <https://github.com/KantaraInitiative/wg-uma/issues/277> - 260 <https://github.com/KantaraInitiative/wg-uma/issues/260>: Cascading authorization servers - Discuss Mohammed's input - Decide next steps - Claim token profiling: 263 <https://github.com/KantaraInitiative/wg-uma/issues/263>: Claim token profiling / 119 <https://github.com/KantaraInitiative/wg-uma/issues/119>: Create an IANA registry for URIs that stand for claim token formats - "Easy issues": - 264 <https://github.com/KantaraInitiative/wg-uma/issues/264>: Authentication-related error details (will close with only editorial/example text) - Shoebox: Will remove V2.0 label from 246 <https://github.com/KantaraInitiative/wg-uma/issues/246>, 245 <https://github.com/KantaraInitiative/wg-uma/issues/245>, 224 <https://github.com/KantaraInitiative/wg-uma/issues/224>, 63 <https://github.com/KantaraInitiative/wg-uma/issues/63>, 24 <https://github.com/KantaraInitiative/wg-uma/issues/24> and make them a parallel activity - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

More set math / Default-deny / Previous RPTs
by Eve Maler 25 Jan '17

25 Jan '17

Domenico created a cool Venn diagram (huzzah!) showing what we've decided for set math thus far. I've attached it below. I believe it's accurate as far as the client-requested scopes, client-registered scopes, and permission ticket go. When it comes to allowed scopes and granted scopes, these unfortunately may be impossible to show in any diagram because the policy conditions that have been configured into the AS are "invisible", and thus the allowed scopes could fall wholly within, fall partially with, or fall totally outside the requested scopes. This means the granted scopes are impossible to show as well. (Unless we show each option in turn, or something.) James and I were talking earlier about how this connects to the paragraph about "default-deny". I'll let James say more about it for further email discussion. Finally, how shall we account for the presence of a previous RPT on a client's request to the token endpoint? In the call, we got as far as saying "The AS would have to find all the claims relevant to having met all the scopes in that RPT. The task in email now is to look at when the previous RPT a) did and b) didn't contain resource IDs that were in the current request for access." Let *PreviousRPT* stand for all the scopes in an RPT present on a client's request at the token endpoint. Presumably, *the reason the client included this RPT* is because *the token failed* when it was trying to accomplish some access over at the RS and *the client would like the AS to upgrade that token, please*. Is that correct? It could have been that the token already had some scope (say, *read*) but didn't have some other scope (say, *write*) for resource ID *123* (say, a file), or it had all permissions for read resource *123* (the file) but no read access for resource *456* (its "enclosing" folder). So the RPT might have permissions *123:read* but not *123:read,write*, or it might have *123:read,write* but not *456:read*. Importantly, it might also have collected a bunch of other stuff that's not relevant to what the client is currently seeking, like *6317:foo,bar,baz* and *83452:man,from,uncle*. Remember that these individual permissions may have individual expiration timestamps on them. What's clear is that *RequestedScopes* as currently defined (whether coming through client reg/req action or through RS permission request action) could have, say, *123:write* or *456:read* in it in order to give the client what it needs right now. If *PreviousRPT* has permission structures in it for *123* and *456*, we can probably say something sensible. What's really not clear yet is: What should happen to the *6317:foo,bar,baz* and *83452:man,from,uncle* permission structures in *PreviousRPT*? Okay, that's an opening bid... What else? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 6

Revs 13 and 05 are up
by Eve Maler 25 Jan '17

25 Jan '17

https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-13.html https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-05.html Key things to note: The biggest thing is that the Authorization Assessment section <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-13.html#authorizatio…> is back, and it's reworked with something like George's example. The discussion of "default-deny" is much much softened. Throughout there are some subtle but -- I think -- helpful changes in response to lots of comments from Cigdem. More of that to come. Based on a discussion with Cigdem (and also the discussions with the HEART WG), I think we need to add a discussion of the importance of the RS treating its permission request practices as a part of its API behavior. Something to discuss... I will send a specific agenda tomorrow -- gettin' late now. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Set math, authorization assessment, and implementation questions (from George)
by Eve Maler 24 Jan '17

24 Jan '17

The following is the "lost email" from George on questions about how the AS might manage registered scopes/resource IDs and the policy conditions that will have to govern the assessment process. ==== I wanted to start a different thread that relates to the "set math" discussion but is more focused on the relationship between resource registered scopes and resource owner policy (ROPolicy). Please correct any incorrect thinking that follows:) In order for a RO to define policy for a given resource, the RS must first register that resource set with the AS. When the RS registers the resource set with the AS, the RS defines what scopes are allowed for that specific resource set. The RO can then go to the AS and find the resource set and define policies that link to the scopes associated with the resource set. Following on my example from the "set math" thread, lets say my photo service registers two resources: rsid_1: photos/gff/landscape scopes: view, link, download rsid_2: photos/gff/family scopes: view, link, download, print When I (as the RO) go to the AS, I'm assuming that I get to define the policy for each of the scopes associated with each of the registered resource sets. Now in practice, I suspect that as the RO, I want an AS that allows me to define sets of claims and then map those to the scopes associated with the different resource sets. Lets assume I've defined the following policy claim sets at the AS. family -- list of individuals that are part of my family photo_viewer -- promises to not download/sell/market any photo I then map the above policies to the resource sets and scopes as follows... rsid_1: view, link -- photo_viewer download -- family rsid_2: view, link, download, print -- family Now, when the client tries to access photos/gff/landscape the RS registers a permissions ticket with scopes for "view" and "link" but not download. The client then presents the permissions ticket to the AS and the AS determines which claims the RqP needs to meet in order to be authorized for those scopes. In this case, both scopes require the same claims (photo_viewer). Now, if the client requested the "download" scope in addition to the scopes in the permissions ticket, then the RqP must meet the family claims in order to get access to that scope. I'm assuming we are leaving it up to the AS to determine whether to fail the RPT request if the RqP can NOT meet the family claim, or return "view" and "link" but NOT "download". The latter feels more like OAuth2 though I'm guessing in more complicated cases this could get dicey:) So RPT request processing at the AS should, I think, be determined by the intersection of the set of scopes defined for the resources set and the set of scopes requested. Simplifying slightly from Justin's set math... scopesToProcess = intersection(Requested, RSReg) The AS then needs to iterate through the "scopes to process" to determine the claims the RqP needs to meet in order to grant an RPT with that set of scopes. for each scope in scopesToProcess { claimsRequired += claims(rsid, scope) } normalize/merge claimsRequired Once the required set of claims is defined, the RqP/client can go through claims negotiation. Depending on which claims are met, the associated authorized scopes can be determined. claims met == promise to not download/sell/market scopes authorized based on claims met view, link If the set of authorized scopes is NOT a super set of the scopes requested in the permissions ticket, the RPT request fails. Otherwise, return the scopes authorized. In this context, I don't think the PrevRPT provides much value, however, a token defining previously satisfied claims provides a lot of value. Does that resonate with how others envision the logic and flow working? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 3

270: Resource Registration Document: 'uri' should be an array / examples
by Eve Maler 24 Jan '17

24 Jan '17

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 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 4