[foaf-protocols] [OpenID] making OpenId RESTful

Allen Tom atom at yahoo-inc.com
Thu Jan 21 03:48:51 CET 2010


[Moving this thread from openid-general to openid-specs]


On 1/19/10 6:23 AM, "Story Henry" <henry.story at bblfish.net> wrote:


>   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.

Hi Henry,

The lack of a standard schema, and the max URL sizelimit (I believe 2048
bytes is the max) needs to be fixed.

Having no standard schema causes interop problems. Defining a basic set of
commonly used attributes (similar to what was previously done for Simple
Registration) should be done in AX 1.1

The redirect URL sizelimit can theoretically be worked around by switching
to HTTP POST - however this does not work acceptably in real-world
deployments because most RPs don't support HTTPS. Returning the response via
HTTP POST from an OP that supports HTTPS to an RP that uses an HTTP
return_to URL results in a scary browser security warning displayed to the
user. Displaying a security warning to the user is an unacceptable UX.

I think the quick hack that will be done in AX 1.1 will be to make the
standard AX attribute names a lot shorter - I believe that it was suggested
(half jokingly) that we use bit.ly URLs. Another possible approach would be
to define the attribute aliases supported by the OP in the OP's discovery
document.

A longer term and more scalable approach would be to define an Artifact
Binding for OpenID - where an artifact (aka a short token) is returned to
the RP in lieu of the AX data. The RP then makes a backend direct server
call back to the OP with the Artifact to get the actual data. Only the
artifact is sent on the browser redirect.

It sounds like Artifact Binding would mostly address the issues that you
pointed out.

Thanks,
Allen




> 
> 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



More information about the foaf-protocols mailing list