<br><br><div class="gmail_quote">On Thu, Jan 21, 2010 at 3:48 AM, Allen Tom <span dir="ltr"><<a href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
[Moving this thread from openid-general to openid-specs]<br>
<div class="im"><br>
<br>
On 1/19/10 6:23 AM, "Story Henry" <<a href="mailto:henry.story@bblfish.net">henry.story@bblfish.net</a>> wrote:<br>
<br>
<br>
> b. the data format is a name value pair with no global namespace. This is<br>
> very limited compared to RDF and creates a very heavy extensibility bottleneck<br>
> c. The data has to be passed inside the redirected URL. So the amount of<br>
> data that can be exchanged is limited to a max of 1024 bytes.<br>
<br>
</div>Hi Henry,<br>
<br>
The lack of a standard schema, and the max URL sizelimit (I believe 2048<br>
bytes is the max) needs to be fixed.<br></blockquote><div><br>I noticed 2083 was quoted in one of the OAuth docs, which I believe is a limitation in some versions of IE<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Having no standard schema causes interop problems. Defining a basic set of<br>
commonly used attributes (similar to what was previously done for Simple<br>
Registration) should be done in AX 1.1<br>
<br>
The redirect URL sizelimit can theoretically be worked around by switching<br>
to HTTP POST - however this does not work acceptably in real-world<br>
deployments because most RPs don't support HTTPS. Returning the response via<br>
HTTP POST from an OP that supports HTTPS to an RP that uses an HTTP<br>
return_to URL results in a scary browser security warning displayed to the<br>
user. Displaying a security warning to the user is an unacceptable UX.<br></blockquote><div><br>Thanks for the heads up. I guess this is also potentially an issue for FOAF+SSL? <br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I think the quick hack that will be done in AX 1.1 will be to make the<br>
standard AX attribute names a lot shorter - I believe that it was suggested<br>
(half jokingly) that we use <a href="http://bit.ly" target="_blank">bit.ly</a> URLs. Another possible approach would be<br>
to define the attribute aliases supported by the OP in the OP's discovery<br>
document.<br></blockquote><div><br>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. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
A longer term and more scalable approach would be to define an Artifact<br>
Binding for OpenID - where an artifact (aka a short token) is returned to<br>
the RP in lieu of the AX data. The RP then makes a backend direct server<br>
call back to the OP with the Artifact to get the actual data. Only the<br>
artifact is sent on the browser redirect.<br></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
It sounds like Artifact Binding would mostly address the issues that you<br>
pointed out. </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Thanks,<br>
Allen<br>
<div><div></div><div class="h5"><br>
<br>
<br>
<br>
><br>
> The above points are just elaborations of what it means for a protocol not to<br>
> be RESTful, which is a serious architectural flaw.<br>
><br>
> An initial solution is quite simple. When the Relying Party fetches the<br>
> OpenId in step 3 of the sequence diagram [2] (this part is RESTful), the<br>
> representation returned currently contains a link to the OpenId server. But<br>
> of course the representation could also contain in RDFa public information<br>
> about the user, or it could link to a public foaf profile [3].<br>
><br>
> But the information available on the openid page has to be public<br>
> information. Here the Attribute Exchange protocol has a not inconsiderable<br>
> advantage as it allows the user at the moment of identification (stage (7) of<br>
> Sequence Diagram [2]) to tell the IDP what type of information the Relying<br>
> Party can receive. This amounts essentially to the user being able to control<br>
> access to the information about him. A lot of people want this. So what is<br>
> needed is to make this part RESTful.<br>
><br>
> It is not complicated to make something RESTful. You need to use a URL to<br>
> point to a relatively stable representation. So here we would need a URL to<br>
> point to a protected description of the user. The user would authorise the<br>
> Relying Party to read such a resource at the same stage (7) as OpenId<br>
> currently uses to decide what information to send bak to the RP. But instead<br>
> of passing all the information back in the redirect URL, the IDP can just<br>
> transmit a URL back to the RP whose dereferences representation contains the<br>
> needed information.<br>
><br>
> AHA! here we have a little problem it seems: if that resource is protected<br>
> then the Relying Party would need to authenticate himself when GETing the<br>
> contents of that resource. If he did not need to do that, then the resource<br>
> would be public - security through obscurity is not good security. OpenId did<br>
> not need this because it achieves server identification through pipe identity,<br>
> by tying the server to the client via an HTTP redirect mechanism. But this<br>
> same mechanism is also what forces it to pass all the values via a URL pattern<br>
> mechanism, severely limiting the amount of information that can be returned.<br>
><br>
> Identifying the Relying Party is not impossible of course.<br>
> There are perhaps 3 ways to do this:<br>
><br>
> A. perhaps by using step (9) of the OpenId sequence Diagram [2]<br>
><br>
> B. Using OpenId:<br>
> This would require one to tell the Relying Party what OpenId login<br>
> service to use, which one could do either:<br>
> + by returning that information in the attributes exchanged with OpenId<br>
> + or at the cost of adding that information to the protected foaf file<br>
> (though this would waste one extra connection, as the Relying Party would be<br>
> required, on first GETing the resource and receiving a 401 containing some RDF<br>
> pointing to the authentication endpoint, to then resubmit the request.<br>
> + embedded in the rdfa of the OpenId document that the Relying Party had<br>
> to fetch at an earlier stage<br>
><br>
> C. FOAF+SSL<br>
> OpenId is a bit heavy in the number of connections it uses. With foaf+ssl<br>
> identification can be done in 2 TCP connections, one of those connections<br>
> being very useful, as it can be a place for the server to find out more about<br>
> the Relying Party.<br>
><br>
> One can do something very similar using only foaf+ssl . This was described<br>
> in "Sketch of a RESTful photo printing service" [4]. Here<br>
> identification/authentication is done in the usual 2 SSL connections. But if<br>
> the Relying Party wants special access to extra non public information about<br>
> the user, it needs to ask him to allow access to that information. In the<br>
> example in [4] the request is simply to allow the printing service access to a<br>
> number of photos. But of course the attributes in the Attribute Exchange can<br>
> be thought of as just another protected resource, and so the same mechanism<br>
> could be used.<br>
><br>
> Perhaps what is missing in the sketch of a RESTful printing service is some<br>
> way for the Relying Party to describe what type of information it is looking<br>
> for. But that looks like something that one should be able to add at a later<br>
> stage.<br>
><br>
> Henry<br>
><br>
> Social Web Architect<br>
> <a href="http://bblfish.net/" target="_blank">http://bblfish.net/</a><br>
><br>
> [0] <a href="http://esw.w3.org/topic/foaf+ssl" target="_blank">http://esw.w3.org/topic/foaf+ssl</a><br>
> [1] <a href="http://openid.net/specs/openid-attribute-exchange-1_0.html" target="_blank">http://openid.net/specs/openid-attribute-exchange-1_0.html</a><br>
> [2] <a href="http://blogs.sun.com/bblfish/entry/the_openid_sequence_diagram" target="_blank">http://blogs.sun.com/bblfish/entry/the_openid_sequence_diagram</a><br>
> [3] <a href="http://blogs.sun.com/bblfish/entry/foaf_openid" target="_blank">http://blogs.sun.com/bblfish/entry/foaf_openid</a><br>
> [4] <a href="http://blogs.sun.com/bblfish/entry/sketch_of_a_restful_photo" target="_blank">http://blogs.sun.com/bblfish/entry/sketch_of_a_restful_photo</a><br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> general mailing list<br>
> <a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
<br>
</div></div>_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
</blockquote></div><br>