[foaf-protocols] [OpenID] making OpenId RESTful
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  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
> 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 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 
> 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" . 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
> Social Web Architect
>  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
> general mailing list
> general at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the foaf-protocols