FWIW, we did discuss a draft of a permission registration extension spec in the past. I had an action to update it according to various group discussion, but hadn't gotten around to it (which is probably a good thing at this point):

https://groups.google.com/forum/#!searchin/kantara-initiative-uma-wg/permission$20registration$20extension/kantara-initiative-uma-wg/CPmbZgh6C14/ZhK0gYYhDwAJ

https://08620661282160442115.googlegroups.com/attach/f218681b41266/draft-uma-permregext.html?part=0.1&view=1&vt=ANaJVrFz2BmAAK2vE2BbfTEGYp6pMRvZ5uK7Mt9QXeOOqqnh09ggm-h_X92gVKk3iIuT_obyW6zgn0jVwvbbt5TVrOKGUv_wADbBiibv5h_Oyr6KpZdneh8


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


On Thu, Jun 16, 2016 at 1:52 PM, George Fletcher <george.fletcher@teamaol.com> wrote:
Sorry for the poorly formatted email... not sure out that happened. Number 2 in the last paragraph is the second option.

Thanks
George

On 6/16/16 1:20 PM, George Fletcher wrote:
I figured I'd send out some suggestions. In looking at the existing spec [1] (hopefully I'm looking at the most current version) there isn't an easy way to add backward compatible support for registering multiple resources sets with the existing POST to {rsreguri}/resource_set.

A couple of options come to mind...


1. If there is only one resource being registered it works as currently defined. If however, multiple are being registered, the what is POST'd is a JSON Array (instead of a JSON object) of the resource set JSON objects...
POST /rs/resource_set HTTP/1.1
Content-Type: application/json
Authorization: Bearer MHg3OUZEQkZBMjcx
...

[ {
  "name" : "Tweedl Social Service",
  "icon_uri" : "http://www.example.com/icons/sharesocial.png",
  "scopes" : [
    "read-public",
    "post-updates",
    "read-private",
    "http://www.example.com/scopes/all"
  ],
  "type" : "http://www.example.com/rsets/socialstream/140-compatible"
  },
  {...}
]

With a response of...

HTTP/1.1 201 Created
Content-Type: application/json
Location: /rs/resource_set/KX3A-39WE
...

[
  {
  "_id" : "KX3A-39WE",
  "user_access_policy_uri" : "http://as.example.com/rs/222/resource/KX3A-39WE/policy"
  },
  {
  "_id" : "DAFS-94SS",
  "user_access_policy_uri" : "http://as.example.com/rs/222/resource/DAFS-94SS/policy"
  }
]
I'm not sure I like this (#1) option as it makes coding a little complicated. 2. Add an effective new endpoint for "batch" registrations. This keeps the new functionality separate. I'm sure there are better mechanisms but a simple one would be to use something like POST {rsreguri}/resource_set/batch. Then, like in example 1 above, the resource sets are POST'd as a JSON array of JSON objects. Thanks, George
[1] https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography

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