OAuth, UMA and the Enterprise

As reported from Phil Hunt Blog, a lot of Interest on OAuth applied to Enterprise scenario have emerged at last IIW#11at Mountain View  (IIW OAuth Enterprise BOF).

Starting in 2008, I have worked on the Sun internal project led by Eve Maler that formed the basis for User-Managed Access (UMA), based on OAuth, and later joined the Kantara UMA Work Group, now as Oracle employee, after Sun acquisition.

I've noted with much interest that the discussed scenarios at IIW BOF are very similar to the scenario and use case that I've proposed and then accepted from Kantara UMA WG, where I'm contributing as leadership team member.

The scenario that I've proposed is about an Online Personal loan request that is a use case in which a user apply a request for a personal loan to a financial service.

In brief, to approve or reject the loan request, the financial service must verify many pieces of user personal information from different Service Provider/host. For instance, the amount of monthly user salary (i.e. 3 last monthly salary) from user's Employer, user bank account information (account number, net) and need to access to the user credit information (credit history, score, ect.) from the Financial Risk central service.

The actors in UMA terminology:

• User as Authorizing User
• Financial Service as Requester
• User's Employer as Host (salary information)
• User Bank as Host (user account information)
• Financial Risk central service as Host (user credit information)
• Authorization Manager

Distinctive aspects:

• The Authorizing User delegates authorization to a Requester to access to Service Providers.
• A Requester that needs a collection of information from multiple sources (resource aggregation).
• A high-value, privacy-sensitive transaction.
• Ensuring that information about the user is third-party verified by using the third parties directly as SPs/Hosts.

Through this and other scenarios UMA WG is developing the next generation user-centric access management platform, based on OAuth 2.0 specification, but with the following key differentiators and capabilities:

• Provide a Centralized Policy Decision Point functionality based on end-user policy.
• Possibility to aggregate protected resources in a single basket to allow the requester to collect data from multiple resources.
• Enhance control on user privacy through an analytics dashboard and auditing to control  who access to what.

Furthermore, in order to address specific trust management issue that can be valuable in the Enterprise scenario, at Kantara UMA WG, we are defining an approach to extend UMA access control mechanism to support trusted Claims. 

The UMA protocol supports the policy-driven ability of an AM to demand claims from a requesting party before authorization is granted. The claims may be self-asserted or third-party-asserted. In this novel approach, UMA leverages  the notion of a Trust Framework (defined by the Open Identity Trust Framework (OITF) Model paper as “a set of technical, operational, and legal requirements and enforcement mechanisms for parties exchanging identity information” and sometimes called a federation).

For more details see last set of wireframes developed to explore a person-to-person data sharing scenario in which the Authorizing User wants to restrict sharing to a specific Requesting Party identity.

It is not complex extend the person-to-person data sharing scenario in a service-to-person scenario, where a Bank service, for instance, to grant access to specific resource to the customers could require specific user-managed trusted claims!!