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?

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.

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?

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.

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:

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.