|Story Henry||Jan 19, 2010 6:23 am|
|Santosh Rajan||Jan 19, 2010 7:06 am|
|Story Henry||Jan 19, 2010 7:27 am|
|ਸੰਜ੍ਯ||Jan 20, 2010 1:12 am|
|Allen Tom||Jan 20, 2010 6:48 pm|
|Pat Cappelaere||Jan 20, 2010 7:24 pm|
|Melvin Carvalho||Jan 21, 2010 1:06 am|
|Story Henry||Jan 21, 2010 1:50 am|
|Story Henry||Jan 21, 2010 2:05 am|
|Allen Tom||Jan 21, 2010 10:12 am|
|Peter Williams||Jan 21, 2010 3:42 pm|
|Subject:||[foaf-protocols] making OpenId RESTful|
|From:||Story Henry (henr...@bblfish.net)|
|Date:||Jan 19, 2010 6:23:05 am|
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  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 :
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  (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 .
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
) 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
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 
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
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
One can do something very similar using only foaf+ssl . This was described in
"Sketch of a RESTful photo printing service" . 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
 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.
Social Web Architect http://bblfish.net/
 http://esw.w3.org/topic/foaf+ssl  http://openid.net/specs/openid-attribute-exchange-1_0.html  http://blogs.sun.com/bblfish/entry/the_openid_sequence_diagram  http://blogs.sun.com/bblfish/entry/foaf_openid  http://blogs.sun.com/bblfish/entry/sketch_of_a_restful_photo