[WG-UMA] RO asynchronous authorization request
Da Cruz Pinto, Marcelo
marcelo.da.cruz.pinto at intel.com
Tue Aug 5 17:31:23 CDT 2014
I like the idea of using the "not_authorized_permission" and adding more semantics using JSON (so that we can provide a bit more of context to the Client on what to do next, maybe even for the Client to instruct the RqP to wait for a message/notification when the request is processed, or other extensions such as polling)... I agree that we want to keep this simple, and your suggestion would accomplish that goal. I do think it's important to think about specifying this, though, since there seem to be a handful of use cases that might require something along the same lines and providing a standard way of doing this will help on the interoperability side of things.
Love the use case on the link btw.
From: Eve Maler [mailto:eve at xmlgrrl.com]
Sent: Tuesday, August 5, 2014 1:59 PM
To: Da Cruz Pinto, Marcelo
Cc: WG UMA
Subject: Re: [WG-UMA] RO asynchronous authorization request
Hi Marcelo-- A couple of thoughts...
To date, this has been solved only at the proprietary "application layer", using a plain "not_authorized_permission" error and sending an email to the RqP when the RO has granted access. The sample app shown in the latest webinar recording (check out minutes 24 through 39) demonstrate this.
There are a number of ways to go if we were to build something into core UMA, something like a way to poll. On the other hand, the easiest thing might be a JSON extension to the "not_authorized_permission" response (in the same way we're extending need_claims for the claim profiling framework) to give hints about when to try again. If the RqP has been refused, it's not really a need_claims situation, more of a "you're not authorized now, but we're checking for you".
If we go back far enough in time, this starts to look like the Liberty Interaction Service, which was probably way overcooked for what it was trying to accomplish. :-) These days, hooking up the AS to the Twilio APIs or something would enable phone-based approvals or similar...and then we'd end up with something like this<http://kantarainitiative.org/confluence/display/uma/UMA+User+Experience?src=contextnavchildmode#UMAUserExperience-Real-TimeConsentGatheredOut-of-Band>!
On 5 Aug 2014, at 11:21 AM, Da Cruz Pinto, Marcelo <marcelo.da.cruz.pinto at intel.com<mailto:marcelo.da.cruz.pinto at intel.com>> wrote:
I've been meaning to ask this question for a while now: We are seeing many scenarios (mostly consumer-oriented) in which the RO policy at the AS is "always ask me", meaning that the RO wants to be explicitly notified by the AS every time an RP wishes to access a particular resource so that proper access can be granted/denied (notification might be sent via email or some other means by the AS). This means that at the moment the Client needs to obtain an RPT (section 3.4.2 and 3.5 on uma-core), there is an asynchronous interaction: The Client somehow needs to be informed that there is temporary condition (maybe an error condition), and it needs to retry the "/authz_request" call later. So far, we've been doing this by creating a custom claim profile which instructs the Client to retry later (potentially providing timing information, if available), but this could also be achieved by having the "/authz_request" call return a temporary HTTP error (although there is no HTTP error code that suits this condition nicely, so the claim profile option seems best)
Thoughts? Has this been discussed in the mailing list already? If a claim profile is the way to go, I think that this is one of those profiles we may want to include on the spec for interoperability reasons.
WG-UMA mailing list
WG-UMA at kantarainitiative.org<mailto:WG-UMA at kantarainitiative.org>
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the WG-UMA