Archive for the ‘OAUTH2.0’ Category
Continuing from the previous post (Part I of the Core Identity series), the goal of a Core Identity Issuer (CoreID Issuer) is to collate sufficient data – aggregate data and non-PII data — from members of a given Circle of Trust in order to create a Core Identity and Core Identifier for a given user (see Figure).
The Issuer performs this task as a trusted member of the Circle of Trust, governed by rules of operations (i.e. legal contract) and with the consent of the user. Architectures and techniques such as MIT OPAL/Enigma can be used here in order for the CoreID Issuer to obtain privacy-preserving aggregate data from the various sources who are members of the Circle of Trust.
The goals of the Core-ID Issuer within a Circle of Trust are as follows:
- Onboard a member-user: The Issuer’s primary function is to on-board users who are known to the CoT community, and who have requested and consented to the creation of a Core Identity.
- Collate PII-free data into a Core Identity: The Issuer obtains aggregate data and other PII-free data regarding the user from members of the CoT. This becomes the core identity for the user, which is retained by the Issuer for the duration selected by the user. The Issuer must keep the core identity as secret, accessible only to the user.
- Generate Core Identifier (unlinkable): For a given user and their core identity, the Issuer generates a core identifier (e.g. random number) that must be unlikable to the core identity. Note that a core identifier must not be used in a transaction. The core identifier value may be contained as a signed certificate or other signed data structure, with the Persona Provider as its intended audience (see Figure).
- Issue Core Assertions regarding the Core Identifier: The purpose of the Issuer generating a core identifier is to allow PII-free core-assertions regarding the user to be created. These signed core assertions must retain the privacy of the user, and must declare assertions about the core identifier.
- Interface with Persona Providers: The Issuer’s main audience is the Persona Provider, who must operate with the Issuer under legal trust framework that calls-out user privacy as a strict requirement. The Issuer must make available the necessary issuance end-points (i.e. APIs) as well as validation end-points to the Persona Provider. In some cases, from an operational deployment view the Issuer and Persona Provider may be co-located or even tightly coupled under the same provider entity, although the functional difference and boundaries are clear.
Eve Maler kindly prepared an excellent set of slides for me to present at IIW#16 in Mountain View, CA late April: UMA_for_IIW16_2013-05
After discussions during the presentation, I believe one of the technical issues that still causes confusion is the fact that UMA uses three (3) distinct OAuth2.0 Tokens:
- AAT Tokens: Authorization API Token — this OAuth2.0 token is used by the Client to prove (to the Authorization Server) that it has authorization to access the APIs at the Authorization Server.
- PAT Tokens: Protection API Tokens — this OAuth2.0 token is used by the Resource Server to prove (to the Authorization Server) that the Resource Owner (e.g. Alice) has provided it (the Resource Server) with authorization to register Alice’s resource at the Authorization Server.
- RPT Tokens: Requesting Party Tokens — this OAuth2.0 token provides authorization for the Requesting Party to access resources at the Resource Server.
Here are the key take-aways:
- All three tokens are OAuth2.0 tokens.
- All three tokens are issued by the Authorization Server (or what used to be called the Authorization Manager in UMA).
- All three tokens should ideally be used in conjunction with the relevant parts of the UMA Binding Obligations (BO) spec. The BO spec tells the parties involved what their legal obligations will be.
I believe the OAuth 2.0 definition of the “client” is too restrictive, and by doing so it has effectively closed-off any possibility of OAuth 2.0 entertaining true third party access on the Internet. Although OAuth speaks in terms Alice-to-Bob sharing of resources, in reality it caters only as far as Alice-to-client sharing (where the “client” is a piece of application software possibly operated by a third party). This point jumps-out clearly when we compare the OAuth view of Alice-to-Bob sharing against the UMA view.
The definition of “client” in OAuth 2.0 (RFC6749) is as follows:
An application making protected resource requests on behalf of the resource owner and with its authorization.
The UMA (draft-06) definition of the “client” is as follows:
An application making protected resource requests with the resource owner’s authorization and on the requesting party’s behalf.
UMA makes the clear distinction between the “Requesting Party” and the Client (or the “Requester”). The Requesting Party is considered to be the human being (or organization, or a human legally representing an organization), while the Client in UMA is the “proxy” entity through which the Requesting Party accesses the resources hosted at the Resource Server. In the UMA view, Bob is the human person who is using the client but may not be in full control of all aspects of the client’s operation.
Nat Sakimura (from the OpenID Foundation) in his recent blog corrects the common misconception that “many people seem to think that this client as “Alice” the resource owner.” I absolutely agree with this view. However, in order to truly support a realistic Alice-to-Bob sharing, OAuth 2.0 needs to expand its definition and understanding of the client.
The following diagram illustrates further. In this diagram, Alice is wanting to let Bob access her calendar so that Bob could adjust his travel itinerary to match Alice’s itinerary. Alice is the owner of her resource (her calendar file) which resides at the Resource Server (operated by MyCalendardz.com). Bob is using the client (the application operated by Tripitz.com) in his desire to access Alice’s calendar file at the MyCalendarz.com. The client is therefore acting on behalf of Bob.
The OAuth 2.0 definition of “client” fails to recognize that a (legal) relationship may exist between the human person (Bob who is driving the “client” application at Tripitz.com) and the company called Tripitz.com. Thus, in the Alice-to-Bob sharing, OAuth assumes that Bob is directly accessing the resources, whereas in reality Bob is more likely to be using his browser to “remotely manipulate” the client application (being operated by a third-party Tripitz.com) to access Alice’s resources at the Resource Server (MyCalendarz.com). The UMA architecture recognizes the real-world reality that Bob will likely need to have an account at Tripitz.com, in which Bob will be required to accept the Terms of Service (TOS) of Tripitz.com.
UMA recognizes (i) the Bob-to-Tripitz relationship and (ii) the Tripitz-to-CopMonkey relationship by requiring two (2) types of OAuth tokens to be presented/wielded by the client:
- The Authorization API Token (AAT): this is the OAuth token that belongs to the client (TripItz.com) and which authenticates the client to the Authentication Server.
- The Requesting Party Token (RPT): this is the OAuth token that belongs to the Requesting Party (Bob) and which authenticates Bob to both the Authentication Server and the Resource Server.
This distinction between the Requester and the Requesting Party in UMA allows legal agreements (i.e. trust framework) to recognize Bob as distinct from Tripitz.com, and accord different legal obligations to these two entities. And from a risk management perspective, it allows finer grain analysis and risk assignments to these entities.
In summary, in order to address the true Alice-to-Bob sharing of resources, OAuth 2.0 needs to:
- expand its understanding of “client” to mean an application being owned and operated by a third party (not Bob).
- add another player to the ecosystem, namely Bob the Requesting Party.
- define that the client is acting on behalf of Bob.
So the news this week was that Eran has decided that OAuth2.0 is a bad specification and wants nothing to do with it. Its kinda a bit too late to complain about OAuth2.0. Its out there, its being used as the basis for many other protocols, such as OpenID-Connect and UMA. Its going to stay around for a while, and perhaps even evolve further. Its a workable solution for this current generation of web applications APIs.
John Bradley got it right: the OAuth2.0 sky is not falling.
PS. I don’t know why people are so upset about the IETF process (see comments by Eran & responses by other folks). How many people in the OAuth WG were around for the creation of IPsec protocol? What about the IKE protocol (starting from Hilary Orman’s ISAKMP draft). All in all it took 5 years at least. Not to mention the PKIX WG (still around after 15 years). This *is* the IETF process. Love it or leave it.