[foaf-protocols] [OpenID] making OpenId RESTful

ਸੰਜ੍ਯ beedi.sanjay at gmail.com
Wed Jan 20 10:12:54 CET 2010


please check the maild before you send mail

Sanjay Beedi

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

More information about the foaf-protocols mailing list