In the previous post, I have shown that the Authentication Service can be made protable and that this is very important to prevent identity loss. One can prepare any number of XRD files and locate it anywhere he wants to make sure that his identity is not going to be lost on the net, as long as he can prove that XRD file is authentic.

How do we prove it?

One way to do it is to obtain the signagure from the Identity Attestation Service (IAS). The job of the IAS is to verify that the user is the rightful owner of the identifier and sign the XRD document presented by him.
The resulting XRD may or maynot have the user’s core identifier, but MUST include the permanent identifier as <Subject> . Of course, the user can self attest but that means he has to have his own cert/key-pair and in general, his ability of being uncorrelatable at the RPs are lost because he has to expose his public key.

So, the user now has a signed XRD. He can place it anywhere on the net. The trust is coming form the IAS, so if either the RP or Authentication Service do not trust the IAS, the flow breaks. In that case, the user should obtain a signed XRD from another IAS.

OpenID 2.0 has a problem such that permanent unique identifier generation is delayed until it gets to the authentication service. As a result, a user has no ability to change the authentication service. This implies that user cannot change the authentication service according to the authentictaion method requirement, he cannot enjoy the failover of the authentication service. Moreover, if the OpenID Authentication Service cease to exist, he will loose his online identity - He will become unable to login to many sites. IMHO, this is the worst weakness of OPenID 2.0. This is not theoretical. With several OP going away recently, this is the reality.

This needs to be addressed.

The way to address it is to leverage on the Discovery service, like XRI. The Discovery Service should return the permanent identifier, and authentication service should just use it.

The flow is like this.

Case 1: User Specified Identifier

In this use case, the user does not care too much to be anonymous to the RP, so he enters his identifier to the RP. This is the basic case.

1. The user access the RP and enters his identifier (Display Name/Alias).
2. The RP finds out the discovery service for the identifer through appropriate bindings. (The simplest case is that the user supplied identifier is the location of his XRD.)
3. The RP obtains the XRD document associated with the identifier.
4. In the XRD document, there is a permanent and unique identifier (Canonical ID/Subject) as <Subject> and bunch of OpenID Authentication Services (AS).
5. The RP choses the highest priority AS and creates AuthN request with Alias+Subject (AuthnReq).
6. The RP sends AuthnReq to the AS. [1]
7. AS authenticate the user by making him enter password etc.
8. AS creates the AuthnResponse and sends it back to the RP.
9. RP verifies the AuthnResponse

Note that by the time it reached the authentication stage, the identifier is completely specified so it makes no difference when on switched the authentication service.

Case 2: OP Identifier

If the user cares to be anonymous, he needs to use OP identifer. This means there is an extra steps before.

1. The user accesses the RP and specifies his Discovery Service (e.g., clicking on the button).
2. The RP redirects user to the Discovery Service (DS).
3. The User enters his identifier
4. The DS generates an XRD with PPID (Pairwise Pseudonym Identifier) and returns it to the RP via browser redirect
5. Upon receipt of PPID, RP starts the process described in Case 1 using this PPID as the user’s identifier.

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.

For those of you who do not know, Chidorigafuchi in Tokyo is one of the best places in the world for Cherry Blossom.

For more photos, see my flicker photo set.

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.