[WG-UMA] RO asynchronous authorization request

Eve Maler eve at xmlgrrl.com
Tue Aug 5 15:59:00 CDT 2014

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!


On 5 Aug 2014, at 11:21 AM, Da Cruz Pinto, Marcelo <marcelo.da.cruz.pinto at intel.com> wrote:

> Hi!
> 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.
> Marcelo.
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-uma/attachments/20140805/2ac94c3d/attachment.html>

More information about the WG-UMA mailing list