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