<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0pt;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
h1
        {margin-top:12.0pt;
        margin-right:0pt;
        margin-bottom:3.0pt;
        margin-left:0pt;
        page-break-after:avoid;
        font-size:16.0pt;
        font-family:Arial;}
h2
        {margin-top:12.0pt;
        margin-right:0pt;
        margin-bottom:3.0pt;
        margin-left:0pt;
        page-break-after:avoid;
        font-size:14.0pt;
        font-family:Arial;
        font-style:italic;}
h3
        {margin-top:12.0pt;
        margin-right:0pt;
        margin-bottom:3.0pt;
        margin-left:0pt;
        page-break-after:avoid;
        font-size:12.0pt;
        font-family:Arial;}
h4
        {margin-top:12.0pt;
        margin-right:0pt;
        margin-bottom:3.0pt;
        margin-left:0pt;
        page-break-after:avoid;
        font-size:10.0pt;
        font-family:"Times New Roman";
        font-style:italic;}
p.MsoHeader, li.MsoHeader, div.MsoHeader
        {margin:0pt;
        margin-bottom:.0001pt;
        border:none;
        padding:0pt;
        font-size:10.0pt;
        font-family:Arial;}
p.MsoFooter, li.MsoFooter, div.MsoFooter
        {margin:0pt;
        margin-bottom:.0001pt;
        border:none;
        padding:0pt;
        font-size:10.0pt;
        font-family:Arial;}
p.MsoTitle, li.MsoTitle, div.MsoTitle
        {margin-top:0pt;
        margin-right:0pt;
        margin-bottom:9.0pt;
        margin-left:0pt;
        text-align:center;
        font-size:16.0pt;
        font-family:Arial;
        font-weight:bold;}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
        {margin-top:0pt;
        margin-right:0pt;
        margin-bottom:6.0pt;
        margin-left:0pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
p.MsoSubtitle, li.MsoSubtitle, div.MsoSubtitle
        {margin-top:0pt;
        margin-right:0pt;
        margin-bottom:18.0pt;
        margin-left:0pt;
        text-align:center;
        font-size:12.0pt;
        font-family:Arial;}
a:link, span.MsoHyperlink
        {color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:purple;
        text-decoration:underline;}
pre
        {margin:0pt;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
p.Quote, li.Quote, div.Quote
        {margin-top:0pt;
        margin-right:36.0pt;
        margin-bottom:6.0pt;
        margin-left:36.0pt;
        font-size:12.0pt;
        font-family:"Times New Roman";
        font-style:italic;}
p.Wiki, li.Wiki, div.Wiki
        {margin:0pt;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
p.Graphic, li.Graphic, div.Graphic
        {margin-top:0pt;
        margin-right:0pt;
        margin-bottom:6.0pt;
        margin-left:0pt;
        text-align:center;
        font-size:10.0pt;
        font-family:Arial;
        font-style:italic;}
span.EmailStyle27
        {mso-style-type:personal-reply;
        font-family:Arial;
        color:navy;}
/* Page Definitions */
@page
        {mso-endnote-separator:url("cid:header.htm\@01C8844C.71FA7740") es;
        mso-endnote-continuation-separator:url("cid:header.htm\@01C8844C.71FA7740") ecs;}
@page Section1
        {size:612.0pt 792.0pt;
        margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
        {page:Section1;}
/* List Definitions */
@list l0
        {mso-list-id:-132;
        mso-list-type:simple;
        mso-list-template-ids:-1328661930;}
@list l0:level1
        {mso-level-tab-stop:90.0pt;
        mso-level-number-position:left;
        margin-left:90.0pt;
        text-indent:-18.0pt;}
@list l1
        {mso-list-id:-131;
        mso-list-type:simple;
        mso-list-template-ids:-909054546;}
@list l1:level1
        {mso-level-tab-stop:72.0pt;
        mso-level-number-position:left;
        margin-left:72.0pt;
        text-indent:-18.0pt;}
@list l2
        {mso-list-id:-130;
        mso-list-type:simple;
        mso-list-template-ids:531935922;}
@list l2:level1
        {mso-level-tab-stop:54.0pt;
        mso-level-number-position:left;
        margin-left:54.0pt;
        text-indent:-18.0pt;}
@list l3
        {mso-list-id:-129;
        mso-list-type:simple;
        mso-list-template-ids:2046339550;}
@list l3:level1
        {mso-level-tab-stop:36.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l4
        {mso-list-id:-128;
        mso-list-type:simple;
        mso-list-template-ids:82112870;}
@list l4:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:90.0pt;
        mso-level-number-position:left;
        margin-left:90.0pt;
        text-indent:-18.0pt;
        font-family:Symbol;}
@list l5
        {mso-list-id:-127;
        mso-list-type:simple;
        mso-list-template-ids:-1405587484;}
@list l5:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:72.0pt;
        mso-level-number-position:left;
        margin-left:72.0pt;
        text-indent:-18.0pt;
        font-family:Symbol;}
@list l6
        {mso-list-id:-126;
        mso-list-type:simple;
        mso-list-template-ids:828961842;}
@list l6:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:54.0pt;
        mso-level-number-position:left;
        margin-left:54.0pt;
        text-indent:-18.0pt;
        font-family:Symbol;}
@list l7
        {mso-list-id:-125;
        mso-list-type:simple;
        mso-list-template-ids:1053828088;}
@list l7:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:36.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:Symbol;}
@list l8
        {mso-list-id:-120;
        mso-list-type:simple;
        mso-list-template-ids:-2021464228;}
@list l8:level1
        {mso-level-tab-stop:18.0pt;
        mso-level-number-position:left;
        margin-left:18.0pt;
        text-indent:-18.0pt;}
@list l9
        {mso-list-id:-119;
        mso-list-type:simple;
        mso-list-template-ids:445916746;}
@list l9:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:18.0pt;
        mso-level-number-position:left;
        margin-left:18.0pt;
        text-indent:-18.0pt;
        font-family:Symbol;}
ol
        {margin-bottom:0pt;}
ul
        {margin-bottom:0pt;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Peter, RE your original question about “So,
what is the Delegate OpenID formally, once read from the metadata? Is it
another class of URN?”, my answer would be “Yes, it is a synonym
being asserted for the original URN.” It’s an example of how the OpenID
Authentication spec specifies identifier synonyms at the abstract identifier
level, vs. redirects at the concrete locator level. In fact this fed back into
the XRI Resolution 2.0 spec, where we added the LocalID synonym element as a
child of the Service element so one of the four XRDS synonym elements (the
other are EquivID, CanonicalID, and CanonicalEquivID) could be used to assert
an OpenID synonym with the same semantics defined by OpenID Authentication.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>One caveat about using the term “URN”–
a formal URN must be a persistent identifier that’s never reassigned. While
OpenID identifiers are abstract identifiers like URNs, but only a subset of OpenID
URLs would meet the persistence requirements of URNs. The same is true of XRIs –
reassignable XRI “i-names” are not persistent, where persistent XRI
“i-numbers” (that use the ! syntax, like =!F83.62B1.44F.2813 or =!F83.62B1.44F.2813!1234)
meet the persistent requirements of URNs. That’s why OpenID
Authentication 2.0 specifies that if a user logs in with an XRI i-name, the RP
must use the XRI i-number asserted as the verified CanonicalID synonym as the
Claimed Identifier.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>=Drummond <o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0pt 0pt 0pt 4.0pt'>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>
<hr size=2 width="100%" align=center tabindex=-1>
</span></font></div>
<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> Peter Williams
[mailto:pwilliams@rapattoni.com] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Wednesday, March 12, 2008
12:41 PM<br>
<b><span style='font-weight:bold'>To:</span></b> Drummond Reed;
general@openid.net<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: [OpenID] Calling
OpenID 2.0 editors (wasRE:ProblemswithOpenIDand TAG httpRange-14)</span></font><o:p></o:p></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
<div id=idOWAReplyText33749>
<div>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt;color:black'>Actually, thinking more carefully about
your email's model, perhaps I should have said (concerning
"concretization/resolution" of the URN ):</span></font><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> <o:p></o:p></span></font></p>
</div>
<blockquote style='margin-top:5.0pt;margin-right:0pt;margin-bottom:5.0pt'>
<div>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt;color:black'>I'm happy with that: OpenIDs are a
subclass of URN, constrained to have http URL syntax (or XRI syntax). OpenID discovery
is the process of transforming the user supplied URN into the claimed ID
URI. (Note this final "URI", in this rewrite).</span></font><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> <o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>My concern for a formal treatment of the Delegate OpenID still stands,
tho. Where present in metadata, the Delegate OpeniD will be used in the openid
auth message, as the claimed id. Yet the user is held accountable at the RP as
the "claimed ID URI" from the resolver. Its the claimed ID, not the
delegate OpenID, that gets account linked by the likes of plaxo, isn't it? I
could have two claimed ID mapping onto 1 plaxo account (by plaxo account
linking), where each of the Claimed IDs maps onto the same Delegate OpenID.<o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> <o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>I supposed the likes of Plaxo could usefully enforce the rule that they
refuse to conclude Plaxo-account-linking two of a user's Claimed IDs unless
they have a common Delegate OpenID. Users providing user entered IDs can then
cite the particular "personality/role" that they wish to be
representing themselves as, to the RP.<o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> <o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>OpenID is getting more interesting. We have (1) the idea that one OP
can cause the RP to hop to another OP (a referal, when acting itself as 2nd/Nth
level discovery agent). And (2), we have the other idea that Delegate OpenIDs
and RP obligations to manage delegateID<->claimedID mappings -- providing
features analogous to some of the flows in the SAML2 nameid protocol. We are
indeed getting to quite a rich identity infrasrtucture.<o:p></o:p></span></font></p>
</div>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>
<hr size=2 width="100%" align=center tabIndex=-1>
</span></font></div>
</div>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><b><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=2 face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> Peter
Williams<br>
<b><span style='font-weight:bold'>Sent:</span></b> Wed 3/12/2008 12:15 PM<br>
<b><span style='font-weight:bold'>To:</span></b> Drummond Reed;
general@openid.net<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [OpenID] Calling
OpenID 2.0 editors (wasRE:ProblemswithOpenIDand TAG httpRange-14)</span></font><o:p></o:p></p>
</div>
</div>
<div>
<div id=idOWAReplyText17904>
<div>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt;color:black'>I'm happy with that: OpenIDs are a
subclass of URN, constrained to have http URL syntax (or XRI syntax). OpenID
discovery is the process of transforming the user supplied URN into the claimed
ID URN. </span></font><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> <o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>An OpenID/URN only has meaning only once its supported by suitable
metadata - obtained from the URN registry (one record of which is represented
concretely using an XRDs file)<o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> <o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>So, what is the Delegate OpenID formally, once read from the metadata?
Is it another class of URN?<o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> <o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> <o:p></o:p></span></font></p>
</div>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>
<hr size=2 width="100%" align=center tabIndex=-1>
</span></font></div>
</div>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><b><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=2 face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> Drummond
Reed<br>
<b><span style='font-weight:bold'>Sent:</span></b> Wed 3/12/2008 11:47 AM<br>
<b><span style='font-weight:bold'>To:</span></b> 'Peter Williams'; 'Brendan
Taylor'; general@openid.net<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: [OpenID] Calling
OpenID 2.0 editors (wasRE:ProblemswithOpenIDand TAG httpRange-14)</span></font><o:p></o:p></p>
</div>
</div>
<div><pre style='WORD-WRAP: break-word'><font size=2 face="Courier New"><span
style='font-size:10.0pt'>Peter, it's a good point that OpenID explicitly deals with identifiers. To<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>be even more precise, OpenID explicitly deals with _abstract identifiers_ --<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>identifiers do not reference a resource directly, but only indirectly via<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>reference to a description of that resource. (URNs are a classic example of<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>abstract identifiers - http://en.wikipedia.org/wiki/Uniform_Resource_Name). <o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p> </o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>Even though it's a URL, an OpenID URL is an abstract identifier because it<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>always resolves to another identifier (the OP URL). It can do that<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>resolution through an HTTP header, and HTML tag, or an XRDS document.<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p> </o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>In the case of an OpenID XRI, it is by definition an abstract structured<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>identifier and resolves to a concrete identifier (or other metadata<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>describing the identified resource) via an XRDS document.<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p> </o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>It's worth highlighting this because synonym management for abstract<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>identifiers takes place at a higher level than HTTP. For example, the XRI<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>Resolution 2.0 spec<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>(http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html) defines<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>four types of XRI synonyms that can be asserted in an XRDS document,<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>together with the synonym verification rules to prevent spoofing. OpenID<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>Authentication 2.0 takes advantage of this by specifying that if the user's<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>OpenID is an XRI, RPs MUST use the XRDS CanonicalID synonym (after<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>verification) as the user's Claimed Identifier. (The main reason for this -<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>preventing OpenID recycling -- is explained in detail in an ACM paper given<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>last week at the IDtrust Symposium -<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>http://middleware.internet2.edu/idtrust/2008/papers/01-reed-openid-xri-xrds.<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>pdf). <o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p> </o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>Although HTTP(S) is used for XRI resolution, the semantics of HTTP redirects<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>plays no part at all in determining or verifying XRI synonyms because these<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>synonym relationships are at the abstract identifier level and not the<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>concrete identifier level.<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p> </o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>I think the same applies to OpenID URLs -- because they are abstract<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>identifiers, the synonym relationships are specified by the OpenID<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>Authentication spec and not by HTTP redirect semantics.<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p> </o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>=Drummond <o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p> </o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p> </o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> -----Original Message-----<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> From: general-bounces@openid.net [mailto:general-bounces@openid.net] On<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> Behalf Of Peter Williams<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> Sent: Wednesday, March 12, 2008 7:43 AM<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> To: Brendan Taylor; general@openid.net<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> Subject: Re: [OpenID] Calling OpenID 2.0 editors<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> (wasRE:ProblemswithOpenIDand TAG httpRange-14)<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> <o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> <o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> <o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> <o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> <o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> OpenID, on the other hand, deals in identifiers. The documents involved<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> are just a convenient way of figuring out what identifiers to use.<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> <o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> <o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> <o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> <o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> Which is along the lines of what I said: we are not using http to collect<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> web resources.<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> <o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> Openid does deal with identifiers, but they are not uris/urls in the<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> formal sense of the uri rfc. Openid uses the syntax, but not the semantics<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> - as to use the semantics would contradict the assumption above (uris<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> identify web resources, including uri references that are resources in the<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> semweb sense, in and of themselves)<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> <o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> We know the compliance argument has been dealt with : other upper layers<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> have already done what openid discovery protocol does: ignore the link<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> management semantics of http redirects.<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> <o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> This leaves the clickthru and the remembering issue - which is valid and<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> pertinent. We could handle it openid.next by improving unsolicited auth,<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> or standardizing openid discovery's use of redirects signals for openid<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> purposes (only) when xris are not involved.<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> _______________________________________________<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> general mailing list<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> general@openid.net<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>> http://openid.net/mailman/listinfo/general<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p> </o:p></span></font></pre></div>
</div>
</div>
</div>
</body>
</html>