[OpenID] OpenId4.me -- Re: Should Openid's resolve to their descriptors in v.next?

Santosh Rajan santrajan at gmail.com
Fri Nov 20 02:05:41 UTC 2009


Hi Henry,
This is a terrific explanation. Thanks. Comments Inline.

On Fri, Nov 20, 2009 at 6:34 AM, Story Henry <henry.story at bblfish.net>wrote:

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



Right. In the cases where there is actually an html document for the
OpeniID.



> 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:
>
> http://blogs.sun.com/bblfish/entry/foaf_openid
>
> > Then we come to the final question. Do we dump the idea of OpenID's
> > resolving to the document page? And make it mandatory for OpenID's to
> > resolve to  the descriptors? Or we need a descriptor format that is
> > compatible and can be merged in to the html? Or we solve the problem with
> > content negotiation?
>
> 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...
>


Right. In the case where the openid does not return an html document, you
need to have the descriptor (XML representation) returned.



> 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.
>
> 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 <
> http://facebook.com/bblfish>. 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...
>
> 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 <
> http://facebook.com/bblfish> 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.
>
> So the question is how does this enhanced Facebook, identify the photo.comservice so that it can return it the correct subgraph of information. Well
> clearly photo.com has to log into facebook.com, ie, photo.com has to have
> it's own OpenId. This could be done by simply having a pointer in the
> Identifier page, <http://facebook.com/bblfish> to an OpenId login point.
> That type of relation would be easy to create.
>
> The problem is that the above will then require the Relying party to
>  1. fetch the openid page
>  2. search for that OpenId login page
>  3. login using openid
>  4. refetch the OpenId page, to get the new more complete representation
>
> 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.
>
> 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.
>
>    http://blogs.sun.com/bblfish/entry/sketch_of_a_restful_photo
>
> 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.
>
>
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.

Thanks again.


-- 
http://hi.im/santosh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091120/62c56a9a/attachment-0001.htm>


More information about the general mailing list