General pattern of protocol flow in OAuth and CX Artifact Binding is almost identical.

Just to assist the OAuth people to understand CX easily, here are the glossary of the terms.

OAuth Terminology	CX Terminology
Consumer Key	Consumer’s Identifier
Consumer Secret (shared between Consumer and Service Provider)	Consumer Certificate. (Only public certs/key is shared and no secret is being shared.)
Request Token Request	Offer
Unauthorized Request Token	Ticket
Request Token Secret	N/A
Authorized Request Token	ContractID
Access Token	Contract
Access Token Secret	N/A
N/A	Transaction ID (cx.id)

Here after, I will write this article in OAuth terminology and express CX terminology like cx:Offer.

Message Flow Comparison

From the message flow point of view, it is completely identical.
The difference is that CX’s version has much richer structure.

For example, cx:Offer (Request Token Request) has “Consumer” identity, its public key, term and conditions, “Consumer” pub-key based signature etc. in it, and cx:Contract (Access Token) has User’s identity, Service Providers Public Key, Service Provider Signature, etc.

Now, let us dive into protocol difference.

(Source: OAuth Core Final 1.0. Click to Magnify)

There are some differences in the details.

In B above, OAuth returns Unauthorized Request Token and Request Token Secret which is used as a part of signature key (consumer secret + token secret) . Unauthorized Request Token is bound to the Local ID of the “Original” User. In CX, it is either not bound to anybody at this stage, or if it is, the Users global identifier (e.g., OpenID) is explicitly written in the Request Token Request (cx:Offer).

In C, to obtain Authorized Request Token (cx:ContractID), the Token is sent (or input) to the Service Provider.

At this point the (hopefully the original) User identifies himself (by something like username and password.) Note that there is no guarantee that the User here is the same User that started off the Request Token Request. This is one source of OAuth Fixation Vulnerability. If the User is the victim of this attack, his local identity at the Service Provider is effectively linked to the attacker’s (Original User’s) identity at the Consumer.

In CX, if the user was not identified at the Consumer, then his global identifier is verified at the Service Provider and written into the Access Token (cx:Contract). If the user was identified at the Consumer, then its global identity is already written in the Request Token Request (cx:Offer), and thus in the Access Token (cx:Contract). Thus, OAuth Fixation vulnerability does not exist here. It is simply not possible to link a user at the Consumer to another user at the Service Provider.

Once the user was identified, and an appropriate authorization/permissioning happens, Authorized Request Token (cx:ContractID) is generated. At this point, the Authorized Request Token is bound to the User at the Service Provider in OAuth. In CX, Access Token (cx:Contract) is generated here as well, and User’s Identifier is written into the Access Token (cx:Contract). Of course, if the identifier in the offer (if not identifier_select) and the identifier of the User at the Service Provider does not match, it fails.

In step D, this Authorized Request Token (cx:ContractID) is returned to the Consumer via browser redirect.

Then, in step E, Consumer requests Access Token (cx:Contract) using Authorized Request Token (cx:ContractID) and Consumer Secret + Request Token Secret as the Key of the signature. In case of CX, we just use Consumer’s secret key to sign the request.

In OAuth, at this point Access Token (cx:Contract) is generated. Note that in CX, it was generated before step D.

In F, Access Token (cx:Contract) and Access Token Secret (cx: no such thing) is returned, which is subsequently used to access resources. In CX, this is optionally encrypted by the Consumer’s Public Key obtained through Request Token Request (cx:Offer), so that nobody but only the Consumer can read it.

Summary

So, to summarize:

1. OAuth and CX is almost identical in the protocol flow.
2. OAuth requires manual step to establish the Consumer’s identifier called Consumer Key, while CX leverages on metadata including its identifier in XRD.
3. OAuth does not require an identity framework such as OpenID while CX does.
4. OAuth uses Token Secrets. In CX, there is no need of them.
5. CX leverages on public key cryptography for security while OAuth depends on shared secret. In another words, in CX, there is no shared secret.
6. Authorized Request Token (cx:ContractID) and Access Token (cx:Contract) is generated at different point in the sequence in OAuth, while it is generated simultaneously in CX.
7. OAuth implicitly assumes that the User at the Consumer and the Service is the same guy and binds a local user at the Consumer to another local user at the Service Provider by Request Token, while CX does not and leverages on the User’s global Identifier to distinguish them.
8. OAuth implicitly assumes that the User in the different point in the sequence is the same guy, while CX does not and leverages on the User’s global Identifier to distinguish them.
9. In CX, the authorization fails if the identifier in the cx:Offer/cx:Contract does not match with the User’s Identifier
10. CX is not vulnerable to the OAuth Fixation Attack, though on the surface, the protocol flow seems almost identical.

Comments on OAuth Vulnerability Fix Proposals

It seems there are two proposals on the table [2].

• Signed Callback URLs
• Signed Approval URLs

IMHO, they are not dealing with the core of the problem. The core of the problem is the identification of the users at each site and the conflation of the potentially different identity over time and location. The above may work for this vulnerability, but it is just patching a hole and not coping with the real problem. I am very sleepy (I have slept only two hours each for last couple of days…) so I might be wrong, but sending the Local ID of the requesting party (the Original User) with the Request Token Request (cx:Offer) and Service Provider prominently showing this to the User might be a better idea.

[Related Articles]

[1] http://oauth.net/core/1.0/
[2] http://oauth.pbwiki.com/OAuth-Session-Fixation-Advisory
[3] http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-session-fixation-attack.html
[4] http://www.readwriteweb.com/archives/how_the_oauth_security_battle_was_won_open_web_sty.php
[5] http://groups.google.com/group/oauth/browse_thread/thread/e9b205c8c21f8f3c
[6] http://apiwiki.twitter.com/Sign-in-with-Twitter

I had a talk with ProtectServe folks yesterday and it inspired something about what Contract has to have.

Until the meeting, the basic items that I had in mind were following:

- Subjects
- Signers (If Subject!=Signer, Singer is a proxy and
asserting that he has the agreement with Subject
implicitly.)
- Human Readable Term Text
- Machine Readable Term
- Date
- Period of the Service
- Consideration for the Service (usually in dollar amount.)
- Liability (usually specifying the limit in dollar amount.)
- Corrective Measures
- Termination
- Confidentiality (May persist longer than the duration of the service.)
- Arbitration
- Jurisdiction

During the discussion, an issue with signing software/hardware came up. From the process point of view, it would be importat to know what was used to sign. Thus, probably, the identifier including versions of the software/hardware combination, or more simply put “System” needs to be recoreded somewhere.

Yes! Finally! Kantara Initiative is LIVE.

Kantara Initiative is a Bridging and harmonizing the identity community with actions that will help ensure secure, identity-based, on-line interactions while preventing misuse of personal information so that networks will become privacy protecting and more natively trustworthy environments. I have been working diligently on this project and I am so happy to see this date.

FYI, Kantara (kan-TAR-a): Kiswahili for “bridge”; Arabic roots in “harmony”, and
Initiative (i-NISH-ee-uh-tiv): an introductory act or step; leading action. When we were discussing the name back in February, the name just clicked inside me. (I grew up in Kenya, where Kiswahili [Swahili Language] is one of the primary language). Bridging and harmonizing the identity community - Is it not appropriate in this seemingly fragmented islands of Identity. Also, the fact that President Obama who is inaugurated this year has roots in Kenya, and the Federal CIO, Vivek Kundra, is from Tanzania and speaks Kiswahili added “timeliness”, too.

Yes, I know that some people in OpenID community/foundation are uncomfortable with the idea. (I do not know why, and I never got a good answer.) However, I strongly believe that we should not live in isolation. Creating Bridges to different islands.

One of the first output of this “Bridging” initiative is the OpenID/SAML Interop of the Concordia Working Group. It is done by NTT/NRI (my company)/Oracle that translates SAML AuthnContext Assertion into OpenID PAPE Assertion and vice versa. At the demo, you can see that one can login to an OpenID site using SAML IdP, login to a SAML site using OpenID Provider, etc.

Later today, I will be a part of Identity Assurance Panel at 3:30pm, so I might touch on it as well.

So, CHEERS to KANTARA INITIATIVE.

Together, we can change the world, cannot we?

I had a two hours talk with Andrew Nash Friday Afternoon around the security of assertion based technologies. It was a very productive meeting and reminded me of several things.

One of the main one is the separation of the responsibility and the liability properties.

From the business perspective, the security decision is always made on the cost benefit analysis basis. Thus, it is important to know what would be the liability of given transaction. i.e., it is important to know the financial and other obligation associated with each transaction. Usually, these are written in a normal contract in two separate section. The main deal and the liability associated with it for a rainy day, i.e., what each party has to pay if they could not fulfill their obligation.

CX has the following items in its standard message:

1. Identifiers of the Parties.
2. The main deal
3. Remedy and Liability
4. Period, Renewal, and Termination
5. Confidentiality
6. Jurisdiction
7. Signatures of the Parties

However, I have not specified that Liability section to have an explicit dollar amount in a structured way. (Well, it used to… but removed after Specs Coucil pointed out that he did not like it.) The discussion with Andrew reminded me of the importance of it, that cost benefit analysis portion of security decisions is so important that it would probably be beneficial to actually specify it in the core message. Needs to explore more.

When OpenID Japan formally started in October 2008, the number of the companies that joined it was 32.

Thereafter, companies continued to join in and as of Apr. 3, it is 48.

The companies that joined after our announcement in October 2008 are as follows:

* (A Magazine who wants to remain anonymous in public)
* 3Di
* Japan Certificate Service Inc.
* Kawaijuku
* Emardio
* Hitachi
* Indigo
* Japan Hewlett Packard
* NTT Data
* NTT Docomo
* NTT Communications
* Mitsubishi Tokyo UFJ Bank
* Digital Garage E-Context Company
* Secom Trust
* Cuon
* Nippon Life Insurance

These additions are somewhat significant. Now, we have the top bank and the top insurance company as our member. Three main mobile carriers are here as well. We are having additional certificate authorities, etc. It now has a very good coverage of industries so that their views can be represented.