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 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.

According to the current XRI TC discussion, it is looking like this.

<xrd>
    <Subject set="beginswith">...</Subject>
    <Alias>...</Alias>
    <KeyDescriptor use="*">
        <ds:KeyInfo>
           ...
        </ds:KeyInfo>
    </KeyDescriptor>
    <ds:Signature>
        <ds:KeyInfo>
           ...
        </ds:KeyInfo>
    </ds:Signature>
    <link>
        <rel>...</rel>
        <uri>...</uri>
        <Subject>...</Subject>
        <ds:KeyInfo>
           ...
        </ds:KeyInfo>
    </link>
</xrd>

Description

xrd/Subject : Type=URI. Subject Identifier or portion of Subject Identifier. CanonicalID in XRDS.

xrd/Subject/@set : (Option) Can specify “beginswith” to signify that the URI is only partial and beginswith the string.

xrd/Alias: Alias URI for the Subject.

xrd/KeyDescriptor: Wrapper element for ds:KeyInfo for the Subject.

xrd/KeyDescriptor/@use : Specify the usage of the KeyInfo, e.g., Signature, Encription, etc.

xrd/ds:Signature: Expresses the Signatory and the Signature over this XRD.

xrd/link: Shows the relationship that this Subject perceives against other subject.

xrd/link/Subjct: the Subject of the linked XRD.
xrd/link/ds:KeyInfo: has the public key of the Signatory of the Subject of the linked XRD. The linked XRD will be signed by the private key that corresponds to this public key, users can verify that the link is actually an inteded one.

Discussion Points

1. Do we really need KeyDescriptor?
2. Do we really need xrd/link/Subject? Would not xrd/link/uri suffice?

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.

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.

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: