Comments on: Discovery and OAuth and UMA – oh my http://www.xmlgrrl.com/blog/2009/11/23/discovery-and-oauth-and-uma-oh-my/ Tangled musings on identity, privacy, trust, and suchlike Sat, 08 Oct 2011 19:31:02 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Eve http://www.xmlgrrl.com/blog/2009/11/23/discovery-and-oauth-and-uma-oh-my/comment-page-1/#comment-261524 Eve Thu, 03 Dec 2009 21:19:40 +0000 http://www.xmlgrrl.com/blog/?p=1915#comment-261524 Hey, thanks for the question and interest! :) Hey, thanks for the question and interest! :)

]]> By: Michael Helm http://www.xmlgrrl.com/blog/2009/11/23/discovery-and-oauth-and-uma-oh-my/comment-page-1/#comment-261523 Michael Helm Thu, 03 Dec 2009 21:02:17 +0000 http://www.xmlgrrl.com/blog/?p=1915#comment-261523 > If authz state changes to “authorized”, the R approaches the protected resource at the H once again Ok - so that's what that loop back to "R known to H" means - recursiive like, rather than exception like. Thanks! > If authz state changes to “authorized”, the R approaches the protected resource at the H once again

Ok – so that’s what that loop back to “R known to H” means – recursiive
like, rather than exception like. Thanks!

]]> By: Eve http://www.xmlgrrl.com/blog/2009/11/23/discovery-and-oauth-and-uma-oh-my/comment-page-1/#comment-261425 Eve Wed, 02 Dec 2009 23:55:51 +0000 http://www.xmlgrrl.com/blog/?p=1915#comment-261425 If authz state changes to "authorized", the R approaches the protected resource at the H once again (going from the upper left of the authz state decision diamond to the top action box). Since the access request is signed this time (R already authenticated and can sign to correlate future requests), the "R known to H" hurdle is cleared. When "H asks AM for allow decision", this time the AM can confirm that the R met all the conditions. We're anticipating a flow like this: The requester first has to get a correlation handle at the host, and subsequently a "referral" host/requester correlation handle at the AM, before getting any farther. (These can be done just once, and then they're all set up for subsequent usages.) The different authz states represent different things that might be going on to qualify the requester to be worthy of access. E.g., "claims required" initiates a terms-negotiation flow (we've just been discussing a <a href="http://kantarainitiative.org/pipermail/wg-uma/2009-December/000311.html" rel="nofollow">proposal</a> for how to do this on our UMA list), and "pending" might account for the time it takes for the AM to check with the user out-of-band (e.g. by sending an SMS or email if that's what the user insists on). "Authorized" is the signal that the requester should attempt access again, in the likelihood of getting it. (Lots of latency between checking state and attempting access might give the user a window in which to change his/her mind and change policy settings to block that requester, though.) If authz state changes to “authorized”, the R approaches the protected resource at the H once again (going from the upper left of the authz state decision diamond to the top action box). Since the access request is signed this time (R already authenticated and can sign to correlate future requests), the “R known to H” hurdle is cleared. When “H asks AM for allow decision”, this time the AM can confirm that the R met all the conditions.

We’re anticipating a flow like this: The requester first has to get a correlation handle at the host, and subsequently a “referral” host/requester correlation handle at the AM, before getting any farther. (These can be done just once, and then they’re all set up for subsequent usages.)

The different authz states represent different things that might be going on to qualify the requester to be worthy of access. E.g., “claims required” initiates a terms-negotiation flow (we’ve just been discussing a proposal for how to do this on our UMA list), and “pending” might account for the time it takes for the AM to check with the user out-of-band (e.g. by sending an SMS or email if that’s what the user insists on). “Authorized” is the signal that the requester should attempt access again, in the likelihood of getting it. (Lots of latency between checking state and attempting access might give the user a window in which to change his/her mind and change policy settings to block that requester, though.)

]]> By: Michael Helm http://www.xmlgrrl.com/blog/2009/11/23/discovery-and-oauth-and-uma-oh-my/comment-page-1/#comment-261422 Michael Helm Wed, 02 Dec 2009 23:36:24 +0000 http://www.xmlgrrl.com/blog/?p=1915#comment-261422 How do you ever get from the "Authorization state pen" to "accesses resource"? How do you ever get from the “Authorization state pen” to “accesses resource”?

]]>