<HTML><HEAD></HEAD>
<BODY>
<DIV id=idOWAReplyText15174 dir=ltr>
<DIV dir=ltr><FONT color=#000000>I like this topic, if only because I think I finally have enough of a handle of semweb theory to understand it. I also have enough mental model about the security controls in an openid infrastructure (woefully under analyzed academically, particularly in the name/address discovery area) to see the design intent.</FONT></DIV>
<DIV dir=ltr>&nbsp;</DIV>
<DIV dir=ltr>On the one hand we are dealing with the core nature of openid discovery and openid auth - the reliance buy these subprotocols on a resource discovery protocol (HTTP) that was never intended to play the role that openid puts it in. "The Web is a specific political experiment in social engineering, dont mess with our manifesto, OpenIDers!".</DIV>
<DIV dir=ltr>&nbsp;</DIV>
<DIV dir=ltr>On the other hand, openid is imposing identity semantics on the internet/web - and need not be limited to the semantics of bearer protocols. "Its just a bit pipe, stupid."</DIV></DIV>
<DIV dir=ltr>&nbsp;</DIV>
<DIV dir=ltr>As OpenID is not really leveraging HTTP in its as-designed role: identify and locate web&nbsp;resources. Openid is certainly not leveraging the use of HTTPS in its as-designed role: obtain assurance for a secure pipe terminating at a certified security-endpoint known as "a website-&gt;DNS binding". Doing neigher of those things, what is it doing? An OpenID OP is really "making a statement about" resources&nbsp;(and one day may even fullfill its vision to make statements about assurance).</DIV>
<DIV dir=ltr>&nbsp;</DIV>
<DIV dir=ltr>With little doubt, I the OP can choose to state that this or that redirect messages (treated as protocol states rather than references to resources) is an OpenID&nbsp;- a notion that need not be tied to URIs or to the smeantics of the HTTP&nbsp;service.</DIV>
<DIV dir=ltr>&nbsp;</DIV>
<DIV dir=ltr>As someone said earlier in this thread, an OpenID happens to be a URL, but that does not mean its a URI - or has URI semantics.</DIV>
<DIV dir=ltr>&nbsp;</DIV>
<DIV dir=ltr>In making statements about statements, perhaps OpenID is more semweb in nature than it realizes.<BR></DIV>
<DIV dir=ltr>
<HR tabIndex=-1>
</DIV>
<DIV dir=ltr><FONT face=Tahoma size=2><B>From:</B> Noah Slater<BR><B>Sent:</B> Wed 3/5/2008 6:01 AM<BR><B>To:</B> Drummond Reed<BR><B>Cc:</B> david@sixapart.com; general@openid.net<BR><B>Subject:</B> Re: [OpenID] Calling OpenID 2.0 editors (was RE: Problems&nbsp;with&nbsp;OpenID and TAG httpRange-14)<BR></FONT><BR></DIV>
<DIV><PRE style="WORD-WRAP: break-word">On Tue, Mar 04, 2008 at 07:55:41PM -0800, Drummond Reed wrote:
&gt; I'm not an OpenID editor but I remember that there was a great deal of
&gt; discussion around this and there was a good reason (security as I recall)
&gt; that the final redirect needed to be treated as the claimed identifier.

I would love to hear this reasoning because it makes no sense to me at the moment.

&gt; 3) From a SemWeb standpoint, I believe the right answer is that ALL the
&gt; identifiers in the chain - the original identifier, all redirects, and any
&gt; "override" back from the OP - should all be considered synonyms for the
&gt; identified resource. In other words, rdf:sameAs statements.

This is incorrect. 303 redirects do not imply rdf:sameAs.

--
Noah Slater &lt;http://bytesexual.org/&gt;
_______________________________________________
general mailing list
general@openid.net
http://openid.net/mailman/listinfo/general
</PRE></DIV></BODY></HTML>