Registering multiple resource sets
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
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
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/permiss... 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" <http://www.example.com/icons/sharesocial.png>, "scopes" : [ "read-public", "post-updates", "read-private", "http://www.example.com/scopes/all" <http://www.example.com/scopes/all> ], "type" : "http://www.example.com/rsets/socialstream/140-compatible" <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" <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" <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 listWG-UMA@kantarainitiative.orghttp://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
participants (2)
-
Eve Maler -
George Fletcher