[OpenID] Should Openid's resolve to their descriptors in v.next?

[Santosh Rajan]

This is something that has me stumped. I am sure this subject has been
discussed in various forms before. But i think we need to clarify this, now
that we are talking about openid v.next.

Let us start with the semantic web folks. According to them the answer is no
(if i have understood them correctly)! eg. if John's OpenID was
http://example.com/john, then according to the semantic web folks
1) http://example.com/john#me is John's OpenID
2) http://example.com/john#home is John's homepage
3) http://example.com/john#RDF is John's resource descriptor. (I am using
RDF, or Atom if you may) instead of XRD because I am pissed off by XRD).

Also they have another solution called content negotiation, (but it does not
matter as far as this discussion is concerned).

Next is OpenID 1.0. According to which John's OpenID resolves to his html
homepage, which will contain his resource descriptor information.

Then we have directed identity, which resolves to nothing really, other that
some "BIG EGOS". This should be dumped, and we should assuage the big ego's
with an acct: URI. Which is actually fair.

Then we come to the final problem of OpenID's and acct: URI's. Both should
resolve to something, and the same thing. The resource descriptor.

Now I firmly believe that identifiers should resolve to their descriptor's.
It is only fair that identifiers resolve to something meaningful. This is
where i disagree with the semantic web folks.

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?

-- 
http://hi.im/santosh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091119/0ee1bf49/attachment.htm>