Abstract

This article describes the concept of (abstract) Contract Exchange, and then discusses the OpenID Binding and Use of the Contracts as Access Tokens. At the end, it also provides a mapping table to User Managed Access (UMA) Terminologies.

About Contract Exchange

Contract Exchange (CX) is a protocol to exchange the signed contract dynamically among the entities in the network. It uses Public Key based signature, so it achieves certain degree of the non-repudiation and ability to prove. Thus, e-commerce etc. should benefit from it. In addition, since it can capture the purpose of the use, condition of the use, provisioning method etc. for the data/attributes, it can be used to achieve the server to server exchange of the data.

Draft OpenID CX is a binding of this Contract Exchange onto OpenID. It takes a form of OpenID Extension. Thus, it can be used over the existing OpenID Authentication 2.0, which is a GET/POST binding, as well as over the artifact binding which has been discussed since last fall. For the exchange of the proposal and contract etc., it is also using Attribute Exchange 1.1 Draft.

Basic Flow of the CX.

The basic flow of the CX has the following flow. Note that this is before binding it to a specific underlying protocol.
In the below, AM stands for Authorization Manager, SP for Service Provider.

1. (SP finds Proposal Template from XRD/S of the AM)
2. SP obtains the proposal Template from the AM.
3. SP specifies the variables in the Proposal Template to create a Proposal.
4. SP signs the Proposal to create a Signed Proposal.
5. SP sends the Signed Proposal to the AM.
6. AM shows the conditions to the user and obtains the authorization.
7. If OK, the AM counter-signs the proposal to create a Contract.
8. AM saves the Contract and sends a copy to the SP.
9. SP uses the Contract to obtain data etc. and provides service to the user.

The service does not necessarily require data transfer. It may even not a service over the network.
However, it is expected that in majority of the cases, it will be a network based service that requires some data transfer.
Under such circumstances, some data transfer protocol needs to be defined in the contract. e.g., OpenID AX, OAuth, Wrap “API Calls”.)

Characteristics of the CX Template

CX Templates has several unique features.

• XML is the default format.
• The template has to have a URL of the form http://uri_of_contract_template#digest_algorithm:digest, so if the template is changed, the url will also change.
• Anyone can create a template, but since AM is the party that knows what data is available as well as the party which creates the permission page, AM seems to be the natural place.
• As the result of the Hashed URL, template cannot be edited. Thus, we have to use variables to express the portion which is given from the outside.
• Template variables are expressed in the form of {{variable_name}}. As the variable name, xs:id of the XML element is used, and the value will be the inner text of the Element.

Characteristics of the CX Contract

• There can be as many parties as one wants. That is, we can express n-party contract. Each Party has Obligations.
• A Contract includes the public key of the each Parties. These can be used for the signature verification and data encryption.
• A Contract includes a TemplteURL and a Template. Ops and RPs can use this TemplateURL to figure out what kind of template it is.
• Obligation can be written in the Contract. This includes the price and damage limit.
• As a default data request method, AX Request is supported. Other format can be defined.
• Signature is done by XML Signature. Canonicalization is Exclusive Canonicalization. Since it is using the Digital Signature, the ability to proof is high even outside the system.

OpenID GET/POST Binding

CX can be bound to OpenID through GET/POST Binding and Artifact Binding. For the purpose of this article, which binding to use is a non-issue, so I am using simpler GET/POST binding flow.

In the next diagram I am using OP (OpenID Provider) instead of AM and RP (Replying Party) instead of SP to match the OpenID terminology. In addition, UA stands for User-Agent (e.g., Web Browser).

Data Transfer using CX

In the use case that transfers data, CX Contract can be used as either the holder-of-key or bearer access token by the RP. Alternatively, if the Data Provider has the copy of the contract, then ContractID can be used as a bearer token. (In general, AM and DP are different, so the later cannot be assumed in every case.) Using such Tokens, server to server data transfer can be achieved. Data Provider (DP) checks the authenticity of the contract and then creates a dataset and encrypts it with the public key in the Contract and provides it to the requestor. Since it is encrypted by the public key of the intended recipient, it cannot be read by somebody else.

Appendix 1: Mapping to UMA terminology

This afternoon, I attended UMA WG session at Kantara Initiative. UMA stands for User Managed Access, formally known as ProtectServe.

The purpose of this Work Group is to develop a set of draft specifications that enable an individual to control the authorization of data sharing and service access made between online services on the individual’s behalf, and to facilitate the development of interoperable implementations of these specifications by others.

Thus, it roughly is equal to CX in it’s concept.

A little bit of comparison was done in today’s session.
Most notably:

In CX, contract proposal is sent from the data consumer to the data provider (user) while in UMA, the proposal is being sent from the data provider (user) to the data consumer.

This is subtle but important distinction, at least, philosophically.

In fact, when I started discussing CX among my friends, we first consider the user providing the policy just like UMA. It was because it is closer to the VRM like setting. Then, after a while, we made a conscious decision to do the other way round.

Why?

In most cases, the data consumer is actually web service. It is a machine. On the other hand, on the data provider side, there is the user, the human being, who makes the decision.

If we offer a contract proposal from the user side, the machine has to negotiate it automagically. It is hard.
It looked like it is an daunting task to do it over a wide range of possible use cases.

On the other hand, the other way round is easy. You show the user the condition and terms, and it is this human being parsing that proposal and making decision. This seemed like a reasonably easy thing to achieve technically.

To approximate user providing the acceptable policy, we can create a common repository of contract proposals and the user can publish the URL in his XRD, so that the data consumer can pick an acceptable policy.

I believe this approach saves us from the hard question of designing negotiation protocol and still achieve something roughly the same. Also, note that we do not have to agree on the syntax of the machine readable condition. It is up to the application to decide it(*1).

We are right now doing CX WG at OpenID Foundation. However, CX is not only for OpenID. I consider it as an OpenID Binding of CX. It can equally be done for OAuth or some other protocol.

UMA’s approach is definitely interesting, but I still do not know how it can be achieved. It is a “must track” kind of thing for me right now.

(*1) There was yet another reason to do it this way: I was not comfortable floating around a contract proposal signed by me waiting for some unknown party to counter-sign floating around. From the “consumer protection” (note different use of the term “consumer") perspective, IMHO, the user should be the last one to sign.

Here is my first cut to the Contract Exchange 1.0 (CX) Draft. It is unfinished, and has lots of places needs text, but essence is there, I think.

Here is the discussion note that I wrote for Contract Exchange.

http://openid.net/pipermail/specs-cx/attachments/20090730/8d9862f8/attachment-0001.pdf

Hopefully, the concept is quite clear and it acts as the level setting ground for the participants at specs-cx.

Now that Contract Exchange WG ML has been set up at openid.net, we should be able to start discussing it.

=hdknr is busily preparing the initial document for the current thought now (which is going to be submit around Wednesday), but I will start introducing concept here little by little. (I thought of using wiki.openid.net but I did not know whether I can control the edits so that we do not get exposed to IPR pollution, so I am doing it here.)

The main concept of the Contract Exchange is to exchange the public key signed contract among “parties”. Basic model calls for two parties, with two additional signatories. Under current situation, Signatories are typically servers.

There will be a contract proposal (offer) on the table to start with. It is signed by the Offerer. The signature achieves two things:

1) Non-repudiation: The offerer really made the offer.
2) Integrity: The accepting party cannot change the offer.

Once the accepting party reads the offer and agrees to it, the contract is established, and to signify it, the accepting party will counter-sign the document.

That’s all what it does.
It could subsequently be used as a token to obtain further data or service, i.e., just like an Access Token of OAuth.

The protocol that we have been talking at various venues (such as IIW) is actually very simple. It is almost a simplified version of OAuth with a tweak.

So, now you understand: There are two important parts in CX.

1) Contract Format
2) Protocol to exchange signed contract.

Of the two, 2) is actually easier, as I mentioned above.

In the following posts, I will talk about each.

ritou’s blog post prompted me to think a little about this issue.

IMHO, there are two reasons.

(1) Cannot trust the RP.
(2) Legal problem.

In the U.S., (1) would be the main problem, I suppose. Thus, white listing through OAuth consumer key or realm based etc. white listing for OpenID seems to be the way.

In other OECD jurisdictions, (2) would be an even larger problem. If it is a decent business, it cannot pass the PII to a third party without permission. Now, to prove that one has this permission is rather problematic, because when obtaining a permission, it has to state the clear purpose and scope of use, which may differ from transaction to transaction. A wholesale pre-agreement does not work here.

That’s why we need some kind of dynamic contract framework such as CX or ProtectServe, which essentially has a Relationship Manager that controls this “contracting” dynamically.

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.

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.