[OpenID] making OpenId RESTful

Tue Jan 19 15:28:17 UTC 2010

On 19 Jan 2010, at 15:06, Santosh Rajan wrote:

> I don't think the issue is about RESTful http. 

Could you explain this in more detail? 

I suppose you don't mean that the issue with making OpenId RESTful - which was the title of the post - is that it is not RESTful. 

It sounds like you think that OpenId has another problem. If that is the case then it will be problematic to cast my answer to one problem in terms of a completely different problem.

> I think the issue is about whether the signatures are synchronous or NOT.

If you think that there is a problem with the synchronicity of signatures I don't see how this is related to REST.

Where in the OpenId sequence diagram here

 http://blogs.sun.com/bblfish/entry/the_openid_sequence_diagram

does the signature problem show itself. And how is that related to the RESTful nature or not of the protocol? 

> So IMHO please do reframe the issue, according to the kind of signatures
> used. I can see where you are coming from, and I want to learn more.

If you help me with the above questions I may be able to recast the problem, if indeed it can be recast. Or I may be able to point you to a solution at the very least.

> Thanks
> Santosh
> 
> 
> On Tue, Jan 19, 2010 at 7:53 PM, Story Henry <henry.story at bblfish.net>wrote:
> 
>> 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
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> general mailing list
>> general at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-general
>> 
> 
> 
> 
> -- 
> http://hi.im/santosh