[OpenID] making OpenId RESTful

[Story Henry]

A quick inquiry into how to replace OpenId attribute exchange with a RESTful protocol using FOAF.

Let us take it that OpenId 1.0 does a good job of identification/authentication. foaf+ssl [0] improves on it in a number of ways, but OpenId has the advantage of being able to function without ssl and with browsers that implement SSL badly. So OpenId is a good intermediate protocol, which furthermore has wide adoption.

But OpenId does a bad job of attribute exchange [1]:
  a. it re-invents protocols for PUT, POST, DELETE methods to add attributes
    (see section 5. Fetch Message, section 6. Store Message, and it even has to re-invent
      success and failure messages, instead of using those from HTTP)
  b. the data format is a name value pair with no global namespace. This is very limited compared to RDF and creates a very heavy extensibility bottleneck
  c. The data has to be passed inside the redirected URL. So the amount of data that can be exchanged is limited to a max of 1024 bytes.

The above points are just elaborations of what it means for a protocol not to be RESTful, which is a serious architectural flaw.

  An initial solution is quite simple. When the Relying Party fetches the OpenId in step 3 of the sequence diagram [2] (this part is RESTful), the representation returned currently contains a link to the OpenId server.  But of course the representation could also contain in RDFa public information about the user, or it could link to a public foaf profile [3]. 

  But the information available on the openid page has to be public information. Here the Attribute Exchange protocol has a not inconsiderable advantage as it allows the user at the moment of identification  (stage (7) of Sequence Diagram [2]) to tell the IDP what type of information the Relying Party can receive. This amounts essentially to the user being able to control access to the information about him. A lot of people want this. So what is needed is to make this part RESTful. 

  It is not complicated to make something RESTful. You need to use a URL to point to a relatively stable representation. So here we would need a URL to point to a protected description of the user. The user would authorise the Relying Party to read such a resource at the same stage (7) as OpenId currently uses to decide what information to send bak to the RP.  But instead of passing all the information back in the redirect URL, the IDP can just transmit a URL back to the RP whose dereferences representation contains the needed information.

  AHA! here we have a little problem it seems: if that resource is protected then the Relying Party would need to authenticate himself when GETing the contents of that resource. If he did not need to do that, then the resource would be public - security through obscurity is not good security. OpenId did not need this because it achieves server identification through pipe identity, by tying the server to the client via an HTTP redirect mechanism. But this same mechanism is also what forces it to pass all the values via a URL pattern mechanism, severely limiting the amount of information that can be returned.

  Identifying the Relying Party is not impossible of course. 
There are perhaps 3 ways to do this:

  A. perhaps by using step (9) of the OpenId sequence Diagram [2]

  B. Using OpenId:
     This would require one to tell the Relying Party what OpenId login service to use, which one could do either:
    + by returning that information in the attributes exchanged with OpenId
    + or at the cost of adding that information to the protected foaf file (though this would waste one extra connection, as the Relying Party would be required, on first GETing the resource and receiving a 401 containing some RDF pointing to the authentication endpoint, to then resubmit the request.
    + embedded in the rdfa of the OpenId document that the Relying Party had to fetch at an earlier stage

  C. FOAF+SSL
     OpenId is a bit heavy in the number of connections it uses. With foaf+ssl identification can be done in 2 TCP connections, one of those connections being very useful, as it can be a place for the server to find out more about the Relying Party. 

  One can do something very similar using only foaf+ssl . This was described in "Sketch of a RESTful photo printing service" [4]. Here identification/authentication is done in the usual 2 SSL connections. But if the Relying Party wants special access to extra non public information about the user, it needs to ask him to allow access to that information. In the example in [4] the request is simply to allow the printing service access to a number of photos. But of course the attributes in the Attribute Exchange can be thought of as just another protected resource, and so the same mechanism could be used.

Perhaps what is missing in the sketch of a RESTful printing service is some way for the Relying Party to describe what type of information it is looking for. But that looks like something that one should be able to add at a later stage.

Henry

Social Web Architect
http://bblfish.net/

[0] http://esw.w3.org/topic/foaf+ssl
[1] http://openid.net/specs/openid-attribute-exchange-1_0.html
[2] http://blogs.sun.com/bblfish/entry/the_openid_sequence_diagram
[3] http://blogs.sun.com/bblfish/entry/foaf_openid
[4] http://blogs.sun.com/bblfish/entry/sketch_of_a_restful_photo