Hi Henry,<div>This is a terrific explanation. Thanks. Comments Inline.<br><br><div class="gmail_quote">On Fri, Nov 20, 2009 at 6:34 AM, Story Henry <span dir="ltr"><<a href="mailto:henry.story@bblfish.net">henry.story@bblfish.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Ah ok! I get it. You are thinking that the OpenId document should contain the description about the person! Yes, why not that could be done in RDFa, for example.<br></blockquote><div><br></div><div><br></div><div><br></div>
<div>Right. In the cases where there is actually an html document for the OpeniID.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
A couple of years ago, as RDFa was not yet finalised I showed how you could use the link relation in the OpenId page to point to an rdf/xml foaf file, and then put information there about the user:<br>
<br>
<a href="http://blogs.sun.com/bblfish/entry/foaf_openid" target="_blank">http://blogs.sun.com/bblfish/entry/foaf_openid</a><br>
<br>
> Then we come to the final question. Do we dump the idea of OpenID's<br>
> resolving to the document page? And make it mandatory for OpenID's to<br>
> resolve to the descriptors? Or we need a descriptor format that is<br>
> compatible and can be merged in to the html? Or we solve the problem with<br>
> content negotiation?<br>
<br>
So I think you can have the OpenId refer to the descriptor, as you say. With RDFa that can work well. It should not be any problem either for the OpenId page to return an RDF/XML representation too...<br></blockquote><div>
<br></div><div><br></div><div>Right. In the case where the openid does not return an html document, you need to have the descriptor (XML representation) returned.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Now I think once you have that, then the final problem that Attribute Exchange architects will find to critique to this set up, and quite correctly I would like to add, is that the information about the user seems to be completely public.<br>
<br>
But content negotiation can help here too. Essentially all one would need to do is to enhance the OpenId resource - the Identifier Resource - to return different rdf enhanced representations, depending on who connects to the page. Imagine for example that FaceBook made my OpenId be <<a href="http://facebook.com/bblfish" target="_blank">http://facebook.com/bblfish</a>>. Then when you look at my page all you will see is just my name and my friends. But if you are logged in and a friend of mine you will see a lot more about me: my address, my latest posts, my latest music habits, etc, etc...<br>
<br>
Now all that we need to do, is do the same as Facebook, but in a distributed fashion. So that means that when the Relying Party - the service that wants to verify my identity, and get some attributes - connects to my page, it has to simultaneously identify itself, so that this enhanced <<a href="http://facebook.com/bblfish" target="_blank">http://facebook.com/bblfish</a>> resource can return it a bit more information - perhaps not as much information as it returns for good friends of mine, but the type of information that I am willing to return to services like photo printing services. Ok, for the sake of making this example more real, let us imagine the Relying Party is a photo printing service.<br>
<br>
So the question is how does this enhanced Facebook, identify the <a href="http://photo.com" target="_blank">photo.com</a> service so that it can return it the correct subgraph of information. Well clearly <a href="http://photo.com" target="_blank">photo.com</a> has to log into <a href="http://facebook.com" target="_blank">facebook.com</a>, ie, <a href="http://photo.com" target="_blank">photo.com</a> has to have it's own OpenId. This could be done by simply having a pointer in the Identifier page, <<a href="http://facebook.com/bblfish" target="_blank">http://facebook.com/bblfish</a>> to an OpenId login point. That type of relation would be easy to create.<br>
<br>
The problem is that the above will then require the Relying party to<br>
1. fetch the openid page<br>
2. search for that OpenId login page<br>
3. login using openid<br>
4. refetch the OpenId page, to get the new more complete representation<br>
<br>
This can be done, but this is where foaf+ssl shines: because it can do all of the above in 1 connection. Ie. the same connection the requests the page, can be the connection that does the identifying.<br>
<br>
Well it should do. This is what I was looking at recently when I proposed to look at how to build a photo printing service using foaf+ssl.<br>
<br>
<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>
This requires some more thinking about. But I think it does provide a beginning of an answer for how one can have attribute exchange be RESTful.<br>
<br></blockquote><div><br></div><div>Great piece of work. This is what i wanted to figure. I am not sure what the XML representation should be. I feel that the RDF model is a bit complicated. The Atom model seems to be very easy. But yes I agree we need two representations analogous to RDF and RDFa.</div>
<div><br></div><div>Thanks again.</div><div><br></div></div><br>-- <br><a href="http://hi.im/santosh">http://hi.im/santosh</a><br><br><br>
</div>