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