Like there can be OpenID GET/POST and Artifact Binding for CX, there can be WRAP binding as well. It is fairly trivial, arguably more trivial than to define OpenID bindings.

1. Send CX proposal as an additional parameter on the Verification Code Request. Use wrap_client_id as the proposer’s identifier.
2. On the PoP verification page, display the terms and conditions included in the proposal.
3. Create the Verification code from the signature of the proposal and some nonce and random.
4. Web App Client sends the proposal again as an additional parameter on Access Token Request.
5. Sign the proposal to create the contract, serialize it with Base64 without line end, and return it as the access token on Access Token Response.

That’s all.

In the current Artifact Binding manuscript, the artifact is being defined as a string shorter than 400 bytes. Some people asked why 400 and not 512, which is the limit of some mobile browsers?

The answer is that we use 80 bytes in the fixed string:

?openid.ns=http://specs.openid.net/auth/2.0&openid.mode=art_res&openid.artifact=

Suppose we use 400 bytes in Artifact. Then, the total is 480 bytes.
That leaves 32 bytes to the non-query portion of the URL.

There has been some talk around Attribute Type URI couple of months ago in OpenID mailing lists. Unless we define a set of widely agreed Type URIs, we will not be able to transfer attributes insuperably. Chris Messina’s summary document on various type URI is very helpful to compare these.

There however is one thing that these specs are missing. The Script types and the language.

Unlike most Western language, some language like Japanese have many scripts within itself. For example, we use “Kanji”, “Katakana”, “Hiragana”, “Romaji (alphabet)” as four distinctive scripts. Often, we are required to supply name and address both in Kanji and Katakana or Hiragana, because without Katakana or Hiragana, you really do not know how to pronounce the Kanji in many cases.

Thus, while it would probably suffice to express fullname just as

http://axschema.org/namePerson

in English, we need these in each scripts.

The problem is how to express these as Type URIs.

One obvious way of approaching it would be something like

http://axschema.org/namePerson#script_name/language_code

where script_name and language_code are optional.

For example,

http://axschema.org/namePerson#kanji
http://axschema.org/namePerson#katakana

would be the Kanji and Katakana version of the fullname.

If the default language for those were not specified, we could further qualify them as

http://axschema.org/namePerson#kanji/ja_JP

If there is only one script for the language, or if it does not matter, we could abbreviate like:

http://axschema.org/namePerson#/en_US

which is the same as

http://axschema.org/namePerson

if the default language was specified as en_US.

What would you think?

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 Article	UMA (User Managed Access)
AM	AM
SP	Host
DP	Protected Resource
UA	Requestor
User	Authorizing User

In case when the site want to use OP Identifier, the site typically shows list of icons of the OPs. This list grows quickly and results in User Interface Nightmare a.k.a. “Nascar Problem”.

Various people have been working on this, such as IDIB efforts and some Infocard integration, but to me, there seems to be even simpler solution.

I have been wondering why nobody proposes this.
It is extremely simple.

Simply add your OP Identifier to the end of User Agent string, separated by semi-colon. For example, if you are using Safari, and if your OP is mixi.jp, then it would be like:

Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9.1;op=mixi.jp

Creating custom header in IE is a bit of problem, but the UA string is an exception and can be changed just by changing a registry entry as far as I know. Most other major browsers provide ways to set the user agents.

The RP, upon receipt of the above string, extracts mixi.jp and redirects user to mixi.jp automagically. If he has a session there, which is likely, he may be returned to the site immediately.

True that it reveals your OP to every site. Some people may consider it a privacy problem, and some would complain about the security implication, but how real would be an attack using that information? Not much, I think. Anti-Phishing? It should be dealt with other mechanisms.

Based on https://openid.pbworks.com/OpenIDwithArtifactBinding

Finally!

I am glad to write that OpenID Foundation Board has approved the change in the OpenID Process document so that a working group can be started without membership vote.

The change itself requires membership vote, so the notice will go out soon, and it is a month or more away for the new process to get effective, but once that is done, we can spin up WGs pretty quickly. That would certainly help AX 2.0, Auth 2.1 etc.

As I was not able to login to comment on Johannes’s blog…

It is about this entry ”Is OpenID User Centric?”.

Johannes’s comment that OpenID being “http://netmesh.info/jernst/digital_identity/is-openid-still-user-centric” is very apt. This is one use case that OpenID is supposed to serve.

The other use case that it is serving right now is the Web SSO.

As a “personal/business card”, you do not need privacy. You do not want privacy. You want to reveal that it was you, and you want to be tracked.

In Web SSO case, you might or might not want to be tracked.

For User Centric thing, I believe that the user should control one’s XRD. Then, I can use Yahoo! or Google as authentication service that provide PPID.

If I want to preserve anonymity, I would use OP identifier to Yahoo! or Google. Alternatively, I could provide an XRD address that service PPID, but that would be a tall order for most people.

If I want to leave my track, then I will provide my (signed) XRD address.

As to the email as attribute being sent…

I think we should define contact service just like XRI people do. It could be email, twitter, or authenticated something, etc. The service should be advertised in the XRD. Then we should not need to provide “physical” address like email to the RP.

I have not been reporting this, but apart from TechNight and BizDay, we are having several discussion groups going on and meetings are getting more like “weekly” than “monthly”. OK. That is not an excuse not writing them here. I will try to be more timely.

Today, I want to report the following:

OpenID BizDay #4

Date: Sept. 25, 2009 (Fri) 14:30 - 16:30
Venue: Vila Fontaine Shiodome Meeting room 2,3
1-9-2 Shinbashi, Minato-ku, Tokyo 105-0021
JAPAN
http://www.sumitomo-rd.co.jp/vf/shiodome/conference/map.html

Program:
“Application of OpenID at NTTCom”
Kazuhiro Kitamura, General Manager, Net Business Div.
NTT Communications Corp.

“gooID that grows with customers”
Yasushi Tsuruki, Manager, Service Dept., Media Div.
NTT Resonant Inc.

So I was designing OpenID Authn Artifact Binding based on OAuth.
OAuth pushes request token (RT) to the Service Provider (saml:responder, openid:op).

Then, I looked back at the saml artifact binding.

It is the opposite. It sends the artifact first and the SP/responder pulls the data from Consumer/requester. Why?

It has got to do with the scale.

When the SP/Responder is big, chances are that the servers are distributed and there will be a big sync up problem among them. Thus, when the RT/message is sent there and the user arrives through browser redirect, the RT/message itself may not be accessible from the server that the user landed.

In case of SAML flow, the requester creates the artifact, and in the artifact, there is a node index included. Then, user arrives to the responder with artifact, and the responder pulls the data using this artifact. When requester receives the artifact, it knows where the RT/message is stored, so it can reliably fetch it.

So, SAML actually is kinder to a large scale providers.

On the other hand, OAuth has its own edge. In case of OAuth, the Requester always makes the action. It does not matter if it is behind the firewall or something. Typically, if it is an application living on a PC or Phone or something like that, the chances are that SP/Responder/OP cannot reach the client because it has got a private address. Since OAuth had such use case from the beginning, I suppose, the current choice was made.

So, coming back to OpenID Artifact Binding: Which design should we chose?

To Pull, or to Push: That is the question.

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.

OpenID Extension is defined in the section 12 of the OpenID Authentication 2.0 as:

An Extension to OpenID Authentication is a protocol that “piggybacks” on the authentication request and response. Extensions are useful for providing extra information about an authentication request or response as well as providing extra information about the subject of the authentication response.

OK. My question: Does it entirely have to depend on authenticaiton request and response, or can it partially depend on it?

By definition, I think it is the later, because, the subsequent paragraph goes:

OpenID extensions are identified by a Type URI. The Type URI MAY be used as the value of an element of an OpenID element in an XRDS document associated with a Claimed Identifier. The Type URI is also used to associate key-value pairs in messages with the extension.

Clearly, this is not authentication request (section 9) and response (section 10), but Discovery (seciont 7.3). Thus, if it were to be entirely on request and response, the spec contradicts itself.

Therefore, it has to mean that an extension is a protocol that has to utilize request and response.

QED

I should be doing this more often:

Japan

- CX discussion group has produced use cases and requirement document on Creative Commons License. Contributors are

Yoichi Ohnawa, NEC BIGLOBE, Ltd.
Takaya Tanaka, KDDI Corporation
Daisuke Ikeda, JCB Co, Ltd.
Takayuki Komatsu, SoftBank BB Corp.
Toru Hada, NEC Corporation
Tatsuo Kudo, Nomura Research Institute Ltd., Editor
Nat Sakimura, Nomura Research Institute, Ltd.
Taizo Matsuoka, Yahoo Japan Corporation
Naoki Koshikawa, Rakuten, Inc.

- Payment Discussion Group is starting in a few week.
As an off spring of the CX Discussion Group, Payment Discussion Group
is starting in Tokyo. It will first evaluate the recent change in the
payment law in Japan, then subsequently disucss the applicability
of OpenID and related technologies on it.

- Ministry of Internal Affairs and Communication has published a request for public comment on the coming substantiative experiment which involves OpenID and SAML interop and uses in Telecos and other entities. (Aug. 6)

- Ministry of Economy, Trade and Industry has put a tender for substantiative experiment on Government-Private Sector Authentication and Identity interoperability, which is likely to be OpenID. (Aug. 4)

- NRI and Verisign Japan announced their intent to start high assurance authentication service based on mobile phone identification, risk based authentication, etc. over OpenID. (Aug. 6)

- NTT has announced that it will support OpenID as “NTT Single Signon Service”. When the service opens, it will be the largest OpenID provider in Japan with over 70 million users. (May 12)

- Numerous miscellaneous press coverages and seminars. We stopped counting them at OIDF-J because there are too many now. OIDF-J now has 52 member companies spanning from the telcos, banks, retailers, transportation, IT, etc.

Europe

- In June, Robert Ott has become the Vice President of OIDE, and is the acting head of OIDE now, as Snorri is extremely busy right now to run his family’s business after his father passed away late last year.

- Jean-Noel Colin is now the representative for Belgium

- OIDE will be representing OpenID in OpenID at EMEX Suisse.

- In autumn, Robert Ott will present OpenID at a Security Event in the IBM innovation center here in Switzerland.

- The major Dutch social website Hyves released it’s support for OpenID in April.

- “OpenID, put into practice” held in Amsterdam, May 12, was a great success.

- CloudViews 2009 held in O Porto, where Nat Sakimura was an invited speaker on identity.

- The largest Portuguese Portal now supports OpenID.

I am pretty sure I am missing many important news. Please let me know so that I can keep the list updated.

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.

In Identity Loss with OpenID 2.0, I have depicted the problem of the current spec. and shown a possible solution verbally. Now, I am presenting it graphically, and with more details.

Let:

OP:=OpenID Provider
RP:=Relying Party
DS:=Discovery Service
AN:=Authentication Service
AP:=Attribute Provider.

Then, in OpenID Authentication 2.0,

OP==DS+AN (+AP)

Final identifier of the user is issued by AN.
This is a source of various problem as I have written in the past.

We can try to separate them out and have the DS issue the final identifier. Here is the sequence diagram for such a case, for user specified user identifier, where

Case 1: User Specified Identifier

USID:=User Specified ID
RPID:=RP’s ID
RPSig:=RP’s Signature over the message
PPID:=Pairwise Pseudonymous ID
CoreID:=Permanent ID of the user, Canonical ID

(fig.1)User Specified Identifier Case (Note: I have omitted LRDD portion.)

Note: Here, I have used PPID, but it could as well be a conventional permanent ID.

Case 2: OP Identifier (identifier_select)

For the case of identifier_select, it would be preceded by:

(fig.2) OP Identifier Case

Replace PPID here with USID in (fig.1) and the rest follows.

XRD

FYI, the user’s XRD that is returned from DS would look like this:

<xrd>
    <subject>example.com/ppid/132435</subject>
    <link>
        <rel>http://example.openid.net/an/1.0</rel>
        <url>https://myop.com/</url>
        <ds :KeyInfo>
             ....
        </ds>
    </link>
    <ds :Signature>
          ....
    </ds>
</xrd>

In the above sequence diagram, there are two XRDs involved: i.e., User XRD, and the AN’s XRD. The authentication endpoint is not written in the user’s XRD. It just has the link to the Authentication Provider and the concrete end point must be obtained from the AN’s XRD.

There are some security features involved here as well.
First, the user’s XRD is signed. Who should sign this XRD is still an open question. It may be application specific. For the interest of privacy, in the above case, I think it should use example.com’s certificate.

You should also note XRD/Link/ds:KeyInfo.
It has a list of public keys in it.
It says that the XRD of the AN must be signed by the private key corresponding to one of the public key in the list. This makes sure that the AN is the service that this user has intended to use.

In the previous post, I have shown that the Authentication Service can be made portable 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 signature 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 may not 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

1. a user cannot change the authentication service according to the authentication method requirement,
2. he cannot enjoy the fail-over of the authentication service.
3. 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 identifier 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 chooses 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.

BTW, this URI in the diagram is in essence a Discovery Service.

Case 2: OP Identifier

If the user cares to be anonymous, he needs to use OP identifier. 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.

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.

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.

OpenID Foundation Japan hosted the OpenID TechNight #4 at GINZA Apple Store on the 10th of February. I went there to attend it straight from Narita Airport.

Almost 120 peopel, which is 1.5 times the capacity of the hall came to attend it.
So, many people were standing, sitting on the isle, etc.

It simply shows the popularity and high interest rate against OpenID in Japan.

We need to capitalize it now because consumer interest will not last.

The lecture was given by tkudo and =zigorou.

After the event, some of us including the both lecturer flocked for a “drink” session, and much talk was done over the mobile profile of OpenID. =zigorou working for one of the largest mobile content provider, and there was another guy from one of the largest Japanese mobile carrier in it. I have recently started a thread on it at specs@openid.net, but I need to push it further. The problem is… I do not have time. Oh well… Is there someone who want to help?!

On Feb. 6, 2009, we had a meeting for OpenID Denmark.

The programme was as follows:

PROGRAM

13.00-13.15 Welcome and Introduction
13.15-13.45 Basics about OpenID and alternative SingleSignOn solutions (Martin Strandbygaard)
13.45-14.15 OpenID Market Development and Use Cases in Japan (Nat Sakimura)

14.15-14.30 Break

14.30-15.00 Status, Opportunities and Roadmap for OpenID (Nat Sakimura)
15.00-15.30 DK User Study: How do non-technical users perceive SingleSignOn (Henrik Biering)
15.30-16.00 Discussion: What is needed to promote the use of OpenID in Denmark?

It had an attendance from wide range of industry including a credit card processors to the national broadcasting corporation.

OpenID in Denmark is just starting, but when combined with its National ID infrastructure, which is going to be in a new version later this year, it has a potential to leap frog most of us. It is worth watching how it is going to evolve.

As of Jan. 1, 2009, apparently, Republic of Lithuania went OpenID. All the Personal ID Card that the Republic of Lithuania issues has OpenID in addition to X.509 in it. Lithuanian government is also going to provide a state run OpenID provider, which is under testing right now.

Congratulations Lithuania!

It’s a kind of pity that I did not know it couple of weeks ago because otherwise I could also have planned to visit Lithuania in this Europe tour.

The original article is in http://openid.net/pipermail/eu/2009-February/000280.html

The election result is now published.
It is at OpenID Board Election Results

Snorri Giorgetti, me, Chris Messina, David Recordon received two year terms and Eric Sachs, Scott Kveton, and Brian Kissel  received one year terms.

I would like to thank all of you for your support to elect me to the two years term.

For those of you who may not be famillier with those people, Snorri has been the main engine for the OpenID in Europe. He established OpenID Europe and has helped over 30 country level chapters to get establisehd in Europe. So, he has been an European counterpart to me (I being co-founding OpenID Japan.)

Chris is running Citizen Agency, and works on DiSo project facilitating the development of “OpenStack” for the social web. Together with David, he is also involved in OpenWeb foundation.

David has been a spokes person for the OpenID community at large, so you probably know.

Eric is heavily involved in the usability side of OpenID. Google’s study of it together with Yahoo! study has been regarded as one of the main input in this field.

Scott is a co-founder and the current chairman of OIDF. He brings with him his 12 years of experience building technology, developing business
strategy and leading engineering teams with companies like Amazon.com,
Rulespace, JanRain and now Vidoop to this community.

Brian has been a real work horse behind the scene. He has been Chairman of the Marketing Committee, co-founded the Customer Research
Committee among other things. We have seen significant increase in the work around OpenID Foundation recently, and that is partly because of his devotion.

I believe OpenID is entering a new phase, and am really excited by the new board. It is international, balanced, and committed. Together with the membership and the community, I am hoping to further advance the UCI.

On Dec. 22, Tokyo IT Newspaper published this year’s buzz word ranking. (http://itnp.net/category_betsu/24/2167/)

The ranking is done in Sumo Ranking style and They are Ranked as “Yokozuna (Grand Champion)”, “Ozeki (Champion, 2nd highest rank)”, “Sekiwake (Junior Champion, 3rd highest rank)” etc.

This year, Yokozuna was iPhone, which was no surprise since it was the first year in Japan. Ozeki was Google Street View, which is no surprise either.

What surprised me though was the 3rd highest rank, Sekiwake, which turned out to be OpenID. It ranked higher than NetBooks (eePCs etc.) or Google Chrome, etc.

Anyhow, it is good to hear something that is assuring our activity.

Here is the complete ranking (Sorry it is in Japanese…)

OpenID Foundation board election is going on till Dec. 24.

I have posted details and my candidacy statement here.

Please have a look.

By the way, here is my picture. This is from my TV appearance.

Since Oct. 30, OpenID Foundation Japan have added 9 corporate members. Many of them are very large corporations. (Since some of them do not want to be identified in public, and I do not have a list who is not, so I am not quoting their names here.) Now, it has 41 corporate members.

The members list is not updated yet, but I expect that it will be pretty soon.

Right after the BizDay #1, Nat rushed to this meeting to give his presentation this council.
This council is supposed to create a national guideline for e-Gov and possibly to the private sector for the usability and identity assurance. Prof. Sudo, an advisor to OIDF-J, is the chairman of this council. (Mr. Mitsushio, a member of OIDF-J, and the leader of the security working group of CIO aide of ministries, is another member of the council.)

For details, see http://www.kantei.go.jp/jp/singi/it2/guide/index.html (Sorry, it is in Japanese.)

The Agenda was as follows:

1. Opening Remarks
2. Status of E-Sigs usage
3. On the “Inference articles” of the e-sig and authentication law.
4. Technical Trends in the technologies that impacts user interface
 4.1 SmartCards and NFC phones
 4.2 Web SSO

I could only attend 4.2 (i.e., my speech) because of BizDay #1 obligation, so I cannot report on anything but my speech and discussion followed it. My presentation was on OpenID and SAML including PAPE and CX proposal, and gave several case studies as well. It was very well accepted. In the following discussion, the importance of the NIST SP800-63 style assurance framework and guidelines that can be used across government and private sectors were noted.

IMHO, this kind of activity is very important for OpenID adoption. There are many companies hesitant to become an RP because the assurance level and legal implication of being a RP is not clear. This kind of council will eventually come up with a national guideline and possibly a new law that covers these and thus make it much easier for something new like OpenID to be adopted.

On Dec. 12, OpenID Foundation Japan had a members only seminar titled “OpenID BizDay#1″, hosted by Yahoo! Japan.
BizDay is something OIDF-J is providing to the members as the benefit of being a paying member.
It is intended to be a forum for the members to share their business (non-technical) experience.

Dec. 12 was the first such occasion, and over 60 people across the industries attended it.

The agenda was as follows:

0. Opening Welcome Message: Koji Yagi, President, OpenID Foundation Japan
1. Keynote: “Next Generation e-government services and security - loosely coupled databases and Government-Industry collaboration.”
     Prof. Osamu Sudo, The University of Tokyo
2. “Yahoo! JAPAN and OpenID”, Tetsuya Nishimaiki, CTO, Yahoo! Japan.
3. “Developments in the U.S.”, Tatsuki Sakushima, NRI-A
4. “Interoperability considerations on ID management: A Concordia Project”, Hiroki Ito, NTT
5. Status report on the progress of OpenID Japan’s activity. Nat Sakimura, NRI
6. OIDF-J Activity Reports, Noboru Uchiyama, OpenID Japan/NRI
7. Member announcements and forthcoming OpenID Japan activities.
 - mixi OpenID Contest, Hiroyuki Oyama, mixi
 - OpenID BizDay #2, Noboru Uchiyama, OpenID Japan/NRI

To start the BizDay #1, Mr. Yagi gave a welcome message to the members for joining this forum.
He also announced that now OIDF-J has 3 additional members: Hitachi, HP Japan, Indigo, that now it has 40 corporate members.

Prof. Osamu Sudo is a renowned government advisor and is an advisor to the OpenID Foundation Japan.
He gave us the current e-gov situation and his insight on how OpenID etc. can help the situation.

Mr. Nishimaki gave an overview on the rationale for Yahoo! Japan to invest and support OpenID, and shared the roadmap with OIDF-J members. Also, he shared business ideas that Yahoo! Japan is considering right now.
It was also good to hear Yahoo! Japan’s basic privacy policy: “The customer owns the information he registered to Yahoo! Japan.”

Tatsuki gave us an update on the U.S. OpenID related development, such as the Board Election, New Working Groups being formed, XRD 1.0 at OASIS Open, etc. Then, he finished off his speach with the mention of OpenID PAPE - SAML Authn Context interoperability project which is supposed to be demoed at RSA 2009. This acted as a good introduction to HIroki’s announcement and introduction of the OpenID-SAML Interop Concordia project.

Nat gave a brief status report on the SIG formation etc. There has been bunch of SIG proposals and the option of starting them simultaneously were considered, but the direction now is to start one to debug the process, and then start others.

Then, Mr. Uchiyama reported on the activities of the past two weeks including Web 2008 Conference that OIDF-J sponsored.

The last portion was member announcement. There were two announcement.

The first one was the announcement of mixi OpenID Competition for students. Awards are going to be given to the teams with implementation that leverage on the social graph represented by mixi OpenID. Juries are composed of two people from mixi, one from OIDF-J, and two others.

The second announcement was the next OpenID BizDay hosted by Japan Airlines. It will be on January 16.
It will feature Japan Airlines’ OpenID strategies as keynote.

Nikkei ITPro Article: http://itpro.nikkeibp.co.jp/article/NEWS/20081212/321354/

On Dec. 10, IdCon #4 was held, hosted by NRI.

IdCon is a gathering of identity engineers and architects started earlier this year by tkudo and =zigorou.
It is a grass-root activity which does not require a membership fee.
It makes a good companion with OIDF-J, which is a for fee membership organization.

IdCon #4 was a fifth such event this year. (We started off from IdCon #0, by the way.)
 
IdCon #4 featured following sessions:

- Possibility of Mobile OpenID, =zigorou, Cybozu Labs.
- Liberty People Service, =hiroki, NTT Information Sharing Lab.
- Recent Developments around OpenID, =nat, NRI
- Drinking Party :pint:

=zigorou gave detailed analysis of the limitation of the current phones available in Japan and the impact of that to OpenID.

=hiroki gave an overview of Liberty People Service.

=nat gave an overview of the recent development around OpenID, such as the board election, new WGs, Dick Hardt going to Microsoft, etc.

One of the feature of IdCon is that it always coupled with drinking party afterwards. It is a very valuable socializing event.

The next IdCon (i.e., IdCon #5) will be hosted by NTT and expected to be around the cherry blossom time so that we can go on an outing for cherry blossom viewing afterwards.

Cool URI for Semantic Web is a very good reading to understand W3C TAG position on what URI are.

Broadly speaking, a URI can represent two type of Resources:
1. Web Document such as Web pages, images, etc. (which is referred to as “Inforamtion Resources” in AWWW)
2. Real World Objects (which is referred to as “Things").

According to W3C guidelines [AWWW], an URI must not represent two different resources/things. Since a Person is not a web page (though that web page may be describing about the person), they must not be represented by a same URI. We need two URIs. In Cool URI for Semantic Web W3C recommends to create URIs in two ways.

(1) Hash URI

This is a document URI + #somestring.

Since any HTTP client strips strings after #, the request sent from the client to the server will be the document URI, so there is no problem in getting the document out of hashed URI.

For example, suppose the identifier that identifies alice was http://example.com/alice#thing, then the URI that goes over the wire will be http://example.com/alice and it is OK to get HTML back since without frangment, it is another URI.

(2) 303 Redirect

Another approach is to create an abstract identifier that identifies the thing, and use 303 redirect to a document (by Location: response header), which may in turn do content negotiation. (Note that the result of the content negotiation must be an equivalent resource.)

Example:

Let http://xri.net/=nat be the ID of a thing.

Then, when requested in GET, it should 303 redirect to a URI of a default web document of =nat with link header describing metadata location.

What about URI based OpenID?

Now, let us think about OpenID in general.

The classic type of OpenID is the Web Page, typically, his home page. This URI is dubbed to be an id of this person as well. This clearly is a violation of  [AWWW] principle. Perhaps putting fragment would somewhat solve the issue but it will have serious usability implication.

The second type is YADIS enabled OpenID, i.e., YADIS ID. (e.g., Yahoo! and mixi.)
In this case, the GET to the OpenID usually derives 200 OK with X-XRDS-Location: header. 2xx response code is reserved for Web Documents, so this also violates [AWWW]. In OpenID 2.1, hopefully, we will reference XRD 1.0 so that it will be changed to 303. If one is using his blog or home page URI as OpenID, he should include fragment but it is a pretty bad user interface-wise.

The third type is XRI.
In this case, 302 redirect is used to serve the default document with X-XRDS-Location: header^*1. Thus, it is also violating [AWWW]. Instead, it should have been 303 instead of 302^*2. In XRI 3.0, it will be 303 redirect with link header, so it will exactly be as in Cool URI for Semantic Web.

Some other thoughts

To save the extra round trip mandated by 303 redirect, it would probably be a good practice to define a path addition to OpenID to create the XRD address, e.g., /+xrd. In the XRI 2.0 HXRI spec, it is ?_xrd_r=application/xrds+xml, but adding /+xrd is a much more appealing way of doing it. After all, <Service> in a XRD is signifying the relationship, and the path component is a selector of the relevant <Service>. So, an XRD corresponding to @free*nat may look like:

<?xml version="1.0″ encoding="UTF-8″?>
<XRD xmlns="http://xri.net/$xrd*($v*2.0)”>
 <CanonicalID>@!1ED4.9ED5.8267.FB80!F2B3.EAAA.6509.55F6</CanonicalID>
 <Service>
  <ProviderID>@!7F6F.F50.A4E4.1133</ProviderID>
  <Type>http://oasis-open.org/xri/xrd-1_0</Type>
  <Path>(+xrd)</Path>
  <URI>http://xri.net/@free*nat?_xrd_r=application/xrds+xml</URI>
 
</Service>
 <Service>
  <ProviderID>@!7F6F.F50.A4E4.1133</ProviderID>
  <Type>http://openid.net/signon/1.0</Type>
  <Path>(+login)</Path>
  <URI priority="2″>http://authn.freexri.com/authentication/</URI>
  <URI priority="1″>https://authn.freexri.com/authentication/</URI>
 </Service>
 <Service>
  <ProviderID>@!7F6F.F50.A4E4.1133</ProviderID>
  <Type>xri://+i-service*(+contact)*($v*1.0)</Type>
  <Path>(+contact)</Path>
  <URI>http://contact.freexri.com/contact/</URI>
 </Service>
 <Service>
  <ProviderID>@!7F6F.F50.A4E4.1133</ProviderID>
  <Type>xri://+i-service*(+forwarding)*($v*1.0)</Type>
  <Path>(+index)</Path>
  <MediaType match="default"/>
  <URI append="qxri”>http://forwarding.freexri.com/forwarding/</URI>
 </Service>
</XRD>

*1 At the time of spec writing, there were no trace of link: header, so this custom header was created.
*2 I kind of remember that there actually was a discussion in the XRI TC whether we should be using 303 or 302, and decided to use 302 because at the time, many browsers did not support 303.

Web 2008 Expo sponsord by OpenID Japan was held in Tokyo on the 3rd of December. 

I did the keynote, and Sakamoto-san of Verisign K.K. did a session on “OpenID in Enterprise” and Seki-san of SixApart K.K. had a session on “OpenID in the internet”.

In the keynote, about 250 people showed up. In the break out sessions, somewhere between 50 to 70 people were there.

To my surprise, almost everybody in the Keynote session knew OpenID, and judging from the hands raised, about 50% has one, 30% have used one, and 15% is still using it.

Seki-san asked another question to the audience in his session: “Are you planning for starting an OpenID based service?”

A lot of them were, which was encouraging.

I had a very good discussion this morning at OASIS Open XRI TC F2F Day 2.

I came up with the XRD SimpleSign Proposal - Three options on Certificate URI locations to chose from, and we discussed pros and cons of those options and came up with a fairly robust result.

See: http://wiki.oasis-open.org/xri/XrdOne/SimpleSign

The key here is to utilize X.509 v.2 field “SubjectUniqueIdentifier” to store CanonicalID into it.
By doing so, the XRD and the certificate is tightly coupled without the need to follow the resolution chain as it has been in XRI Resolution 2.0.

Thus, this XRD can trivially prove that it is authoritative for the entity with the CanonicalID (SubjectUniqueIdentifier), and can serve Public Key Cert: i.e., can be used for Public Key Discovery. Also, this XRD will describe what service this entity offers, or with what service this entity has preferred relationship with.

IMHO, it is a very powerful tool, and I am so excited with it.
It can add a security layer that OpenID et al. needed so badly.

It might change the world, at least in a small way

:hammer:

Based on the discussion this afternoon at iiw#7, here is my initial thoughts on the “policy/principle” and “criteria” that a VRM compliant service should fulfill. They actually are the underling abstract model of the proposed OpenID TX extension (now renamed to be something like CX, contract exchange), OpenID CX being a profile of it onto the OpenID framework.

Policy/principle:

• User owns his own data - he has full authority and control over them.

Criteria:

• User offers his own data to the vendors for a particular purpose on consent to meet his/her needs.
• Vender/Service must present a very specific data usage purpose clearly and must abide to it.
• Duration for the data usage and storage must be defined.
• User must be able to cancel the contract with an appropriate wind down time.
• User must be able to download all his data in a standard format from the vendor/service.
• User is able to delete his data at the vendor/service anytime he wishes except for the data the vendor is required to keep for legal compliance.
• Notification method should the violation to the contract term arise for each party must be defined.
• Restitution measures must be defined for the cases of inappropriate data usage and data leakage.

Tools^*1:

• All the above must be included in the relationship contract and mutually digitally signed with date.
• For long-term contracts, third party time stamping (digital signature with newer algorithms and date) must be done regularly to cope with algorithm compromise risk.
• All the data transfer/exchange must occur based on this contract.

In OpenID CX (formally TX), there will be a mutually digitally signed contract format defined with request-response protocol for creating it. All the subsequent data exchange will occur based on this contract. It would appear to me that the r-button state with joined sideway Us are nothing but the state that the above contract is in effect.

Note: An extremely long thread has started off from this message of mine to the ProjectVRM list. You may want to see them as well.

^*1 I have modified the original message a bit by separating out the Tools from the Criteria. Paul Madsen pointed out that it would be better not conflate Criteria with Tools and I fully agree. Thanks Paul!

Today, I have presented the concept of Trusted Data Exchange and Reputation Service at iiw2007b.

Am writing an article in iiw wiki, but submit succeeds only sporadically.

Had a problme with Linksafe login, so to create the article, I am using =sakimura which is being hosted at 2idi, but that is me, =nat. This seems to be the problem that was introduced in conjunction with the introduction of CardSpace as one of the authentication method.

Conversations:

with =eekim and =ovdavis: ref linking of inames crossing over the ibroker.

with Ashish Jain: Necessity of Reputation service for the distributed authentication and data exchange service to be useful, esp. on the RP reputation.

with Paul Trevithick: Higgins and the contract format.

with =wes of Authentrus (city of Osmio, ITU eTrust initiative, The World Trust Signatories Association):

Authentrus provide the remote enrollment technology (online, telephone, etc.)

Other notes from =wes: Use iname or OpenID as DN in X.509 certificate. On the importance of enrollment/registration. Certification/Registration/AuthN/AuthZ.

I have given a session on OpenID Japan success today.

See:

This afternoon, OpenID Foundation Japan held a press conference with its 32 member companies. It is the first time that the member companies are announced to the public. It was also announced that OpenID Foundation Japan is now accepting the members from wider community.

Also, it has announced the partnership with Liberty Alliance Japan SIG to further the harmnonization effort.

The member companies announced were:

Asahi Net (ISP)
Automation Research Associates (IT)
Cerego Japan (Education)
CyberTrust (CA)
Excite Japan (ISP/Portal)
Infoteria Corp.C (IT)
Japan Airlines International (Transportation)
Japan IBM (IT)
Japan Verisign (CA)
JCB (Credit Card)
K Opticom (ISP)
KDDI (telco)
Lin Network (IT/Consulting)
Livedoor (Portal/Web 2.0)
Mitsui Sumitomo Insurance Co. Ltd.(Insurance)
mixi Inc. (SNS)
NEC (Manufacturing)
NEC Biglobe (ISP/Portal)
Nifty (ISP/Portal)
Nomura Research Insititute (IT/Consulting)
Oki (Manufacturing)
Rakuten (Internet Commerce/Financial)
SBI Holdings (Financial group)
Senshukai Co. Ltd.(Internet Commerce)
Seven Bank (Banking)
SixApart (Web 2.0)
Softbank BB (telco/ISP)
Sonpo Japan Systems Solution (Insurance Systems)
Taihei Computer (Financial Systems)
Technorati Japan (Web 2.0)
Yahoo! Japan (Portal)
Zakura (Web 2.0)

It is quite notable in the sense that now financial institutions such as banks and insurance companies are now on board.

In the presentation, it was announced that it is going to do the following:

[Techinical]
- Technical Seminar Series “OpenID Tech Night”
- Create Implementation Guidelines
- Discuss potential extensions
- Translation of the documents
- Tech Competition and public experimentation
- Special Interest Groups (e.g., User Interface,
assurance, payment)

[Business]
- Creation of case studies and seminars
- Taking statistics
- Business Idea Competition
- Research on the legal aspects
- Business Seminar “OpenID BizDay”

[Public Relation]
- Seminars for pres people
- Seminar with extrernal organizations
- Web site
- Helping out to promote the OpenID services
of the members.

The press conference was well attended with 45 press people including one TV (TV Tokyo).

In conjunction with it, Excite Japan has announced the availability of OpenID to its users. Also, Rakuten Kantan Kessai (Easy Payment) was publicly introduced as OpenID based service. It probably is the second instance of OpenID based service involving payment.

For more details, contact : contact@openid.or.jp

Accroding to the survay by internet.com and marsh research which was conducted over 300 internet user (50% male, 50% female, 20% each of 20s, 30s, 40s, 50s, 60s), 263 of them were using sites that requires authentication. Among them, 28% of them knew about OpenID, and 15% were using OpenID.

Since the number of sample is pretty small, and the distribution is not equal to the demographic pattern, there apparently is much more error than some other survay. Even then, it is an encouraging number.

Remember: a similar survay back in February where only 12% knew about OpenID and only 1.2% of them were using it. Awareness is 250% and usage is 12 fold!

We are close to the take off, I guess.

I wonder if there are similar statistics for U.S. and E.U…

If you know the figure, please let me know!

So, the last week was such a big week for OpenID in Japan.

Here are the list:

Oct. 2: Sourceforge.jp started to offer OpenID based login. It also supports i-names (XRI)!

Oct. 3: JAL expanded OpenID data sharing partnership to another Hotel reservation agent. (Note: this is using TX proposal, and typically transacting something between US$100 to $300.)

Oct. 6: NEC Biglobe started offering BIGLOBE OpenID, which is entirely based on TLS and EV-Certs.

Oct. 6: Rakuten, the biggest internet commerce site in Japan, started to offer “Rakuten Payment” based on OpenID. (I hear that Rakuten’s average sales per transaction is around US$80. I may be wrong…)

There are other backlogs with “Transacting OpenID” that I know but I cannot speak right now.

Japan is going towards the “transacting OpenID”.

I wonder if it is happening else where.

~ Consideration for the next version of OpenID ~

HTTP based OpenID is insecure. We should not use it.
HTTPS based one is much better, but still has problems.

Consider the following case.

Case:

There are two companies, ABC Inc, and XYZ Corp. Both of them are Japanese and have .co.jp domains.
Let these domains be abc.co.jp and xyz.co.jp respectively.

These companies were each providing OpenID in their respective domains for their members.

Consider the case that ABC Inc. and XYZ Corp. merged.

By the rules for .co.jp domain, the merged company can keep only one .co.jp domain.
Let this be xyz.co.jp. Thus, abc.co.jp was released for reuse.
Note that under this circumstances, it is impossible to redirect from abc.co.jp to xyz.co.jp anymore.
Thus, we face a problem that stems from the fact the a domain name cannot be persistent in some cases.

Problem 1: (OpenID Migration at RPs)

Since abc.co.jp is transferring its users to xyz.co.jp, and the OpenID that they were issuing was domain based,
there needs to be mechanism to migrate those disappearing abc.co.jp based OpenID to xyz.co.jp based one.
Unfortunately, there is no method defined to achieve this, and currently it is impossible to do so in a standardized manner.

This result in either or both of the following two corollary problems:

Problem 2: (RP account loss)

Since the users of abc.co.jp based OpenID loses his OpenID, he will become unable to access the RPs that he had been using unless the RP provides an ability to associate multiple OpenID to a local account, or a way for the migration. Neither of them are defined in the spec.

Problem 3: (RP Account impersonation, aka OpenID reuse)

Since abc.co.jp is assigned to a new company, it is entirely possible that the same OpenID including a fragment is assigned to somebody else.
A malicious party may actually launch this kind of attack by establishing a new company and obtaining abc.co.jp for this particular purpose.

The root of the problem seems to stem from the very fact that domain is not persistent.
This means we must not be using domain name based identifier as the claimed_id securely.

Solution:

The solution to this problem would be to use a non-domain based unique persistent identifier
which allows the parties to prove the ownership of it as claimed_id. i.e., we have to be using an identifier that are:

P1. Persistent
P2. Globally unique
P3. Easy to find out if it is a legitimate one (i.e., it should be easy to find out if somebody else uses it as his identifier.)

Candidate 1: (Public Key)

One can use his public key as the claimed identifier.
It can trivially fulfill P3. P2 is true as long as he keeps his Private Key to himself only.
It will be persistent as long as he does not have to change his private key.

In fact, the last one, “persistent as long as he does not have to change his private key” is a rather problematic statement.
There has been cases such as Debian PRNG problem, which forced many people to change his private key.

Candidate 2: (Registry based unique string coupled with Public Key pair.)

This candidate is Candidate 1 pushed a little further. Here, instead of using Public Key as the identifier directly, we use a unique string as the identifier and couple it with the public key pair and register the pair at one of the registry. The registry has to make it sure that the identifier is unique.

In this case, the relying party can search the registry for the identifier and find out the public key associated with it. By checking the signature in the assertion with this public key, RP can tell whether he is dealing with the legitimate person or not.

A typical example of this kind of registry is a certificate authority. A certificate authority can issue a unique string and include it in the certificate. In this case, the identifier must contain the identifier of the CA as a part of it to avoid colliding identifier across the CAs. Having the CA identifier inside the id itself allwos the receiver of the id to evaluate its authenticity based on the certificate. Problem of this approach is that one is tied to a CA and will not be able to change it.

Another example of this type of identifier is XRI. One can find an authoritative signed XRDS that contains the public key from the persistent unique identifier (i-number). This is very close to the certificate approach, but it is not tied to a CA. However, it does require a priori defined root of resolution chain in the system.

Conclusion

HTTP and HTTPS based OpenID are facing problems 1-3.
Among the current OpenID types, only XRI is safe in this respect.
The community should seriously consider using non-domain based claimed_id coupled with public key with appropriate registry such as a Certificate Authority.

OpenID RP Module for Xoops JP.
==============================
Author: Nat Sakimura (=nat)
Date: 2008-02-10
Copyright: Nat Sakimura (=nat)
License: GPL
Version: 0.2
PHP OpenID Library: php-openid-2.0.0

DOWNLOAD
========
http://www.sakimura.org/modules/mydownloads/visit.php?cid=1&lid=8

INSTALL
=======

1. Unarchive the files under modules/ directory.
2. Define XOOPS_TRUST_PATH somewhere out of the web accessible path
in mainfile.php
3. Create a foloder