If you saw the ProtectServe status update from the Internet Identity Workshop in May, but haven’t taken a look since then, you’ll want to check out our progress on what has become User-Managed Access (“UMA”, pronounced like the actress…).
The proposition still centers on helping individuals gain better control of their data-sharing online, along with making it easier for identity-related data to live where it properly should — rather than being copied all over the place so that all the accuracy and freshness leaks out.
On our wiki you’ll now find a fledgling spec that profiles OAuth and its emerging discovery mechanisms XRD and LRDD. We’re also starting to collect a nice little bunch of diagrams and such, to help people understand what we’re up to. Click on the authorization flowchart to get to our “UMA Explained” area:
Thanks to the Kantara Initiative participation rules, it’s easy and free to join the UMA group. If you’re interested to contribute use cases or thoughts on design or implementation talents, consider coming on board.
How do you ever get from the “Authorization state pen” to “accesses resource”?
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.)
> 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!
Hey, thanks for the question and interest! :)