Hi guys, I’d like to question a basic assumption in UMA as it’s defined now. I have a use case where a query to the RS concerns several resource sets. Typically a problem you will have when you’re dealing with hierarchically organized or grouped information. According to 3.2.1 ”The body of the HTTP request message contains a JSON object providing the requested permission” Note! the ’a’. I’d like it to be a list ! Such that I can bind one ticket to a set of permissions not just one. The other option is that I gather a set of tickets, one per permission, return them to the client which then gets the AS to binds them to one RPT. I’d prefer the first option. — Roland 'Look, that's why there's rules, understand? So that you think before you break ’em.’ - Terry Pratchett
You’re not alone. There’s an issue for approximately this: https://github.com/KantaraInitiative/wg-uma/issues/152 We considered doing this prior to V1.0, but it didn’t quite make the cut for some reason. We even briefly considered telegraphing in V1.0.1 that we were planning to expand this eventually, so sure were we that we’re going to do this eventually (it’s backwards incompatible, so technically a V1.0.1 candidate). Our initial thinking (I believe) was that multiple permissions would go in and a single ticket would come out. Of course, now that you bring up an option B for how to do it, if people create extensions on their own without WG guidance, we’ll get incompatibilities out in the wild, which would be a shame. :-) Does it make sense to write up a “third-party profile” just to propose a standardized way to do it that everyone can agree on/like, and then we can flow that into V1.1 or whatever when the time is right? Eve
On 5 Oct 2015, at 11:09 PM, Roland Hedberg <roland.hedberg@umu.se> wrote:
Hi guys,
I’d like to question a basic assumption in UMA as it’s defined now.
I have a use case where a query to the RS concerns several resource sets. Typically a problem you will have when you’re dealing with hierarchically organized or grouped information.
According to 3.2.1 ”The body of the HTTP request message contains a JSON object providing the requested permission”
Note! the ’a’. I’d like it to be a list !
Such that I can bind one ticket to a set of permissions not just one.
The other option is that I gather a set of tickets, one per permission, return them to the client which then gets the AS to binds them to one RPT.
I’d prefer the first option.
— Roland 'Look, that's why there's rules, understand? So that you think before you break ’em.’ - Terry Pratchett
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
6 okt 2015 kl. 18:03 skrev Eve Maler <eve@xmlgrrl.com>:
You’re not alone. There’s an issue for approximately this:
https://github.com/KantaraInitiative/wg-uma/issues/152
We considered doing this prior to V1.0, but it didn’t quite make the cut for some reason. We even briefly considered telegraphing in V1.0.1 that we were planning to expand this eventually, so sure were we that we’re going to do this eventually (it’s backwards incompatible, so technically a V1.0.1 candidate).
Our initial thinking (I believe) was that multiple permissions would go in and a single ticket would come out.
That, I think, is the way to go.
Of course, now that you bring up an option B for how to do it, if people create extensions on their own without WG guidance, we’ll get incompatibilities out in the wild, which would be a shame. :-)
Personally I don’t like option B. It opens up for a Client to mix and match between tickets it has received.
Does it make sense to write up a “third-party profile” just to propose a standardized way to do it that everyone can agree on/like, and then we can flow that into V1.1 or whatever when the time is right?
Your proposal in the issue referenced above works for me. The right time is now :-) — Roland 'Look, that's why there's rules, understand? So that you think before you break ’em.’ - Terry Pratchett
participants (2)
-
Eve Maler -
Roland Hedberg