On Thu, Jan 21, 2010 at 3:48 AM, Allen Tom <[email protected]> wrote:
> [Moving this thread from openid-general to openid-specs] > > > On 1/19/10 6:23 AM, "Story Henry" <[email protected]> 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. > I noticed 2083 was quoted in one of the OAuth docs, which I believe is a limitation in some versions of IE > > 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. > Thanks for the heads up. I guess this is also potentially an issue for FOAF+SSL? > > 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. > May not be as far fetched as it sounds. In the mobile phone world aggressive compression is standard where you are limited in capacity. A 'codebook excited' solution/library may be effective, though perhaps lacks some extensibility, and may be a little on the complex for most. > > 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. > Interesting idea, though it adds another connection, it may be worth it. In this case you could be agnostic of the data format, returning key/value pairs, FOAF/RDF or ATOM as necessary. > > 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 > > [email protected] > > http://lists.openid.net/mailman/listinfo/openid-general > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
