[foaf-protocols] [OpenID] making OpenId RESTful

Santosh Rajan santrajan at gmail.com
Tue Jan 19 16:06:34 CET 2010

I don't think the issue is about RESTful http. I think the issue is about
whether the signatures are synchronous or NOT.

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.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100119/63a19a80/attachment-0001.htm 

More information about the foaf-protocols mailing list