<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:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" 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 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@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:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoToc2, li.MsoToc2, div.MsoToc2
{mso-style-priority:39;
margin-top:3.0pt;
margin-right:0in;
margin-bottom:3.0pt;
margin-left:12.0pt;
font-size:10.0pt;
font-family:"Arial","sans-serif";}
p.MsoToc3, li.MsoToc3, div.MsoToc3
{mso-style-priority:39;
margin-top:3.0pt;
margin-right:0in;
margin-bottom:3.0pt;
margin-left:24.0pt;
font-size:10.0pt;
font-family:"Arial","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</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>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'><br>
<b>Sent:</b> Sunday, November 01, 2009 9:32 AM<br>
<b>To:</b> 'Santosh Rajan'<br>
<b>Cc:</b> 'general@openid.net'<br>
<b>Subject:</b> RE: [OpenID] host-meta and "acct:"<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoToc2><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>If you read <o:p></o:p></span></p>
<p class=MsoToc2><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoToc2>10.2
SAML...................................................................................................................................
60<o:p></o:p></p>
<p class=MsoToc3>10.2.1 Service Type and Service Media Type.............................................................................
61<o:p></o:p></p>
<p class=MsoToc3>10.2.2
Protocol.........................................................................................................................
61<o:p></o:p></p>
<p class=MsoToc3>10.2.3 Recursing Authority Resolution........................................................................................
62<o:p></o:p></p>
<p class=MsoToc3>10.2.4 Client Validation of
XRDs...............................................................................................
63<o:p></o:p></p>
<p class=MsoToc3>10.2.5 Correlation of ProviderID and KeyInfo
Elements............................................................... 64<o:p></o:p></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>in the origin al XRI 2.0 draft doc, you see the rules the
processor of the *<b>original</b>* XRD format must follow (in order to embue
the signed blog as a being “SAML token” type – for
“SAML-assured” name resolution amongst other purposes).<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Now, from what I can tell, the use of SAML markup for xrd
signing had nothing to do with SAML as we know it now in its SSO guise: folks
just borrowed the markup (as was proper) to fashion a method of signing XRDs,
much as Microsoft applied similar markup in cardspace signaling. <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>In doing so, folks could also borrow the semantics of the core
SAML controls that go with SAML type processing. These seems to have been
largely about ensuring that the resulting blob acted as a
“token” - once removed from its issuing context. So,
you can think of the XRI/XRD servers as an early forms of STS: a signed
blob server and signed blob verifier, given the (naming and trust) contexts
that the TTP-grade name-serving apparatus of ibrokers wanted to manage.
Its an idea with a LONG tradition attached (from the secure directory world).<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hmm. “Token”, “once signed”,
“removed from its context”. Sounds a bit like a signed
host-meta – an blog XRD sitting on a file server doing what a HTML file
with a few meta tags for links would also do, except it’s a
“bit” easier to parse (I suppose).<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Now, the host-meta I-D implies that one can sign the elements
(having included a subject field). But, in the transition from XRI to XRD 1.0,
the subject is now just a URI (vs an XML element that used to be able to bear
an xml:id reference).<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>This is what I for my want to know all about - from IETF. How
does one sign an host-meta profiled XRD, considering the content of the subject
in particular. For all I know, given the evidence from XRDS-simple, they are
going to have us do what sort of thing they proposed there, where the URI in
the subject field will have a fragment on the end, indicating the xml:id value.
<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>We don’t know, and we should. Evidently (given the syntax
change), it ain’t gonna happen the way it happened in the era of the
XRI-based signed XRD. For all we know, folks may even decide that the
“xml:id control” (and the providerId control similarly) from the
“SAML-era” signed XRD are not even necessary now.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I’m far too far from a standards committee to even guess
at their thinking about security models. But, meantime, it’s hard to
write correctly structure code for the handling the signed type, mean time. <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>We kind of got away from the thread’s subject line, no!<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal style='margin-left:.5in'><b><span style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Peter Williams [mailto:home_pw@msn.com] <br>
<b>Sent:</b> Sunday, November 01, 2009 8:14 AM<br>
<b>To:</b> 'Santosh Rajan'<br>
<b>Cc:</b> 'general@openid.net'<br>
<b>Subject:</b> RE: [OpenID] host-meta and "acct:"<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Yes. Only the XRD element has
an xml:id attribute, schematically. But I could not detect your point, of
saying this fact.<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>And, a subject name is about
an XRD in a context (in general). One such context is the native signing/trust
model (if used).<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>In the secured variant, the
signature metadata has internal an reference within the stream representing the
value. (That’s just how xml dsig works…, irrespective of XRD
typing). Csnider now the the security model of XRD vs blob signing (where the
additional security controls make the XRD into a certificate, essentially) the
referencing model is reinforced: the subject has to refer to the same
internal-stream identifier as was resolved by the xml dsig library.<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Its not that the xmldsig
library has to confirm/validate the subject. That’s the function of the
validation logic attached to the XRD type itself, as its constructed from the
stream. That logic implement the security model of the type (XRD).<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>I’m going to
assume that the next generation of XRD library (moving beyond
openxri’s initial attempt) will have at least two factories: one derived
from the specification of an unsigned XRD type, and one for signed types. The
factory for signed types will construct class instances that can enforce the
xrd.subject rules. The more basic factory will not. IN fact, an instance as it
constructs from the stream will throw an exception if the subject field is
present (according to todays profile spec).<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>AS I said once before, I
think you are on the right tack challenging the IETF writeup on xrd.subject . Its
just got the wrong focus. It’s not that it MUST always exist per se, but
when it does exist (in the signed variety), IETF should be defining the profile
for that variant too. In that way, the conflicts between the issues of
context-free XRDs and the issues signed XRD can be resolved, and folks know
what to do… when signing host-metas. <o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal style='margin-left:1.0in'><b><span style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Santosh Rajan [mailto:santrajan@gmail.com] <br>
<b>Sent:</b> Sunday, November 01, 2009 7:59 AM<br>
<b>To:</b> Peter Williams<br>
<b>Cc:</b> general@openid.net<br>
<b>Subject:</b> Re: [OpenID] host-meta and "acct:"<o:p></o:p></span></p>
</div>
<p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:
12.0pt;margin-left:1.0in'>Hey Peter, please note that the xml:id refers only
XRD root element as per the XRD 1.0 spec.<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:1.0in'>On Sun, Nov 1, 2009 at 9:17 PM,
Peter Williams <<a href="mailto:home_pw@msn.com">home_pw@msn.com</a>>
wrote:<o:p></o:p></p>
<div>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'>Its (arguably)
better that the ASN.1 SIGNED macro it replaced. That’s because one get to
insert various value/type resolvers into the process (which existed in theory
in the ASN.1 days, but not in reality). Its obviously real, in the XML tooling
era.</span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'>Now…remember
the comment that xrd.subject is REQUIRED n signed XRDs? Now you have the
explanation! The subject has to bear the xml:id (so one cannot spoof historical
references, when the hash algorithm’s trength starts to fail in the
future). Now, the crypto types will tell you to ensure there is lot of
redundancy in the id component o the xml:id, much like in VeriSign serial
numbers there is also lots of redundancy – preparing for the day when the
particular cipher starts to fails completely (like MD5) and folks get a much
smaller search space to attack you on!</span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'>Peter.</span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><b><span style='font-size:10.0pt'>From:</span></b><span
style='font-size:10.0pt'> Santosh Rajan [mailto:<a
href="mailto:santrajan@gmail.com" target="_blank">santrajan@gmail.com</a>] <br>
<b>Sent:</b> Sunday, November 01, 2009 7:41 AM</span><o:p></o:p></p>
<div>
<div>
<p class=MsoNormal style='margin-left:1.0in'><br>
<b>To:</b> Peter Williams<br>
<b>Cc:</b> <a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<b>Subject:</b> Re: [OpenID] host-meta and "acct:"<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'> <o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt;
margin-left:1.5in'>If you look at the XML DSig spec there is no association
with any content of the signed XML Doc itself. But I must admit my knowledge of
XML DSig is pretty rusty.<o:p></o:p></p>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'>On Sun, Nov 1, 2009 at 8:55 PM, Peter Williams <<a
href="mailto:home_pw@msn.com" target="_blank">home_pw@msn.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><span style='font-size:11.0pt;color:#1F497D'>The xml:id in
the attribute grammar for the XRD element is still needed for the optional
digital signing feature. (Using xml:id is how xml dig sig resolvers work, by
default; so the library know which bit of the XML document they are typically a
part of they need to hash). On these grounds, it’s not a ROTFL issue (*).
</span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><span style='font-size:11.0pt;color:#1F497D'>One has to be
careful when signing things playing the role of certificates (vs any other
class of signed type). One needs to get the references right. (Go see how in
XRI 2.0 the xml:id is in both the certified name as well as in
signature’s own metadata referring to the XMl element to be
signed).</span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><span style='font-size:11.0pt;color:#1F497D'>When I did the
XRI/XRD trusted resolver coding (basically, just finishing off what someone
else had mostly already done in the openxri java source tree), I used the
default resolver of the apache dig sig library to resolve the xml:id field in
the DOM tree representing the XRD typed value.</span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><span style='font-size:11.0pt;color:#1F497D'>When I did later
experimented with my own resolvers built on the above success (and obviously no
conforming to any standard), I used the http resolver from the apache dig sig
library, initially. This is when I started wondering… well is the
fragment on that http URI essentially playing the role of xpointer (which can
point to such as xml:id in an incoming stream)?</span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><span style='font-size:11.0pt;color:#1F497D'>Then I got into
semweb, which teaches not to fall into the xpointer type of trap, and let
metadata describe what that http name is all about. Don’t point at format
level constructs by address; do refer to semantic constructs by name.</span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><span style='font-size:11.0pt;color:#1F497D'>This all made
sense (since dig sigs typically are semantically-unaware, and properly act on
serialization formats (i.e. its propert to use an xml:id class reference). But,
then I got into “higher” xml-design issues address
semantic-security claims - where the blob signer signs not the value in
question but merely a outlier value tied to the signature. It then refers to X.
X are commonly security tokens bound to SOAP headers (see the ws-security
world). But… X can be also be seen as a descriptor – i.e. metadata
that describes external resources using resource description frameworks (be
they XRDs, or RDFs).So it became fun to sign an XRD, where the XRD describes
the semantic-security of other XRDs. But, I was just playing around. So…
ignore!</span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><span style='font-size:11.0pt;color:#1F497D'>(*) xml dsig is
a ROTFL matter, since it was born out of rejection of the 2 paragraphs ISO took
to specify how to canonicalize BER-encoded TLVs. The DARPA folks trained in
cold war doctrine hated it (mostly because it was ISO defined, where ISO was
evil by definition, since it included evil commie contributions). SO… the
mindset helped engender what we now have…in the xml dsig world (where it
takes entire books to explain its canonicalization process …based on
pattern matching). While it would make sense if anyone used xmldsig in
“intelligent mode”, it doesn’t in practice make sense: as
folks only typically use Xml-dsig for purposes identical with the thing that
took ISO 2 paragraphs to describe!</span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><span style='font-size:11.0pt;color:#1F497D'>But I think
it’s all ultimately working out for the better. It is time we dumped the
ASN.1-signed cert, and moved to a signed XRD that looks like at least
something design during the lifetime of the web! Ideally we would move straight
to a signed graph, but I dont see much evidence of that happening soon (because
of canoncalization issues, again!)</span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.5in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:2.0in'><b><span style='font-size:10.0pt'>From:</span></b><span
style='font-size:10.0pt'> Santosh Rajan [mailto:<a
href="mailto:santrajan@gmail.com" target="_blank">santrajan@gmail.com</a>] <br>
<b>Sent:</b> Sunday, November 01, 2009 6:24 AM<br>
<b>To:</b> Peter Williams<br>
<b>Cc:</b> <a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<b>Subject:</b> Re: [OpenID] host-meta and "acct:"</span><o:p></o:p></p>
</div>
<div>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:2.0in'> <o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:2.0in'>Hehe Peter, another worm out of the XRD can. Why does XRD 1.0
need to define a xml:id for XRD, given that it is the root element of the XRD,
there can only be one?<o:p></o:p></p>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt;
margin-left:2.0in'>ROTFL if anyone has forgotten this acronym, it is
"Rolling ON The Floor Laughing".<o:p></o:p></p>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:2.0in'>On Sun, Nov 1, 2009 at 3:15 AM, Peter Williams <<a
href="mailto:home_pw@msn.com" target="_blank">home_pw@msn.com</a>> wrote:<o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:2.0in'><br>
Im tempted to say that the xml:id they used (in the abandoned initiative) a<br>
relic of the days when folks were still thinking about simplifing a sequence<br>
of XRDs, and the file recovered might need the locator to point out a<br>
particular one of several i the file (by denoting the xml:id on the XRD<br>
level element.)<br>
<br>
Be interesting to see if LRDD or webfinger has a non HTTP locator concept<br>
(based on that kind of xpointer-like URI). presumably it would only point to<br>
such as a "see also other XRD" location, rather than point out a
sub-element<br>
(such as a particular link). This could retain from the XRI days something<br>
of what used to be attached to the old ref (vs redirect) signal - and be<br>
used to the same management/authority transfer issues.<o:p></o:p></p>
<div>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:2.0in'><br>
<br>
<br>
Peter Williams wrote:<br>
><br>
> I compared the work product you referenced with<br>
> <a href="http://xrds-simple.net/core/1.0/" target="_blank">http://xrds-simple.net/core/1.0/</a>
(an abandoned work).<br>
><br>
> Just note the sheer difference in writing style! While staying within the<br>
> scope of the IETF work item, the I-D will ideally go back to the mixed<br>
> description/specification style of the pro-genitor work.<br>
><br>
> Once one becomes a formal WG chair, it's tempting to be so concise and<br>
> embue such logical correctness into English terms while specification<br>
> writing that it ends up sounding like one of those immortal OSI standards<br>
> from CCITT/ISO - written in a technical language that only 3 people in the<br>
> world could speak natively. And they all sat on the committee.<br>
><br>
> The earlier work I cited does address an issue I dont understand - once<br>
> cast into current XRD 1.0 and host-meta terms. See<br>
> <a href="http://xrds-simple.net/core/1.0/#go_fetch" target="_blank">http://xrds-simple.net/core/1.0/#go_fetch</a>
(last paragraph). The topic is<br>
> refering to elements of an XRD, given the locator url and its fragments.<br>
><br>
> The problem I had initially with your criticism, if you recall, had<br>
> ignorant ol' me focussing on the XRD.Link.Subject (vs XRD.Subject). I<br>
> wanted the URI (with fragment) to refer to a particular link element, in<br>
> order that the metadata in the link acted as descriptor for that (naming)<br>
> URI. This seemed to align XRD and openid identifiers with semweb. This<br>
> would allow us all to observe only 1 religion about names and addresses.<br>
><br>
> In the abandoned work, fragments on (I think) "returned"
locators in such<br>
> as the HTTP Response X-XRDS-Locator URI (or a meta's http-equiv content<br>
> value) could have fragments, which might have pointed to a particular<br>
> element link within the XRD, once retrieved. The fragments had seemingly<br>
> special relationship to the xml:id value (an XML construct) on the link<br>
> element rather than the link.subject (an XRD construct) in the link<br>
> markup.<br>
><br>
> For my part, I now struggle on that topic with the current proposal: what<br>
> concepts got dropped or recast in new form? Things start to swirl.<br>
><br>
> Was the XRDS-Locator different to a 301, 302 or 303, in some subtle way?<br>
> Was there some inner subtlety about using xml:id (given its relationship<br>
> to DOM3 trees)? Was there a hookup with issues of xml dsig signing (and<br>
> its default resolvers)? Did the whole issue just disappear? if so, why and<br>
> what cost?<br>
><br>
> Some of this context is what the IETF I-D needs to bring back, rather than<br>
> be so parsimonious and doctrinal about domains are XRi-like authorities,<br>
> authorities in URI schemes are an embodiment of XRI-like authorities,<br>
> domains and domain-names have a mystical relationships to authority<br>
> fields scheme (and thence to the authorites governing an RDF graph<br>
> node)..... cocnepts that only the higher initiates in the identity gang<br>
> can comprehend.<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> <a href="http://xrds-simple.net/core/1.0/" target="_blank">http://xrds-simple.net/core/1.0/</a><br>
><br>
><br>
><br>
><br>
><br>
> Santosh Rajan wrote:<br>
>><br>
>> <a href="http://www.ietf.org/id/draft-hammer-hostmeta-01.txt"
target="_blank">http://www.ietf.org/id/draft-hammer-hostmeta-01.txt</a><br>
>><br>
>> If you have read the spec above, you will wonder where did the
"acct:"<br>
>> scheme come from. It came from webfinger. The host-meta spec has been<br>
>> work in progress for a while now. Its predecessor was the
"site-meta"<br>
>> spec. The idea of webfinger came later, in may 2009,and the idea of<br>
>> "acct:" about two months back. Given that webfinger is to
follow<br>
>> host-meta, the question is "How come host-meta is following<br>
>> webfinger?".<br>
>><br>
>> Think about it. There is an obvious attempt to legitimize the
"acct:"<br>
>> scheme here. That is not a bad idea. I like it actually. Consider<br>
>> this. If I type "<a href="mailto:acct%3Asantrajan@gmail.com"
target="_blank">acct:santrajan@gmail.com</a><br>
>> <<a href="mailto:acct%253Asantrajan@gmail.com" target="_blank">acct%3Asantrajan@gmail.com</a>>"
into my browser location bar, my browser<br>
>> would retrieve my XRD. Now this is an extreme example. But I hope you<br>
>> get the idea. If not please ask me.<br>
>><br>
>> Unfortunately I have a problem with this idea, even though I like it,<br>
>> this is not the way to do it. The problem is that if you want to<br>
>> legitimize "acct:" you need to be a software engineer
contortionist.<br>
>> You need to "Reject" Subject from the host-meta, and you
need to add<br>
>> "Scope" into the host-meta.<br>
>><br>
>> My contention is that if you really want to this, (and I like the<br>
>> idea), let us get all the DNS, w3c folk on board and do it. Doing it<br>
>> via the "backdoor" is going to cause more harm to the
"identity<br>
>> movement" than good.<br>
>><br>
>><br>
>> --<br>
>> <a href="http://hi.im/santosh" target="_blank">http://hi.im/santosh</a><br>
>><br>
>> _______________________________________________<br>
>> general mailing list<br>
>> <a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a><br>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-general"
target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
>><br>
>><br>
>> -----<br>
>><br>
>> Santosh Rajan<br>
>> <a href="http://santrajan.blogspot.com" target="_blank">http://santrajan.blogspot.com</a><br>
>><br>
><br>
><br>
<br>
--<o:p></o:p></p>
</div>
</div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:2.0in'>View this message in context: <a
href="http://old.nabble.com/host-meta-and-%22acct%3A%22-tp26079872p26146197.html"
target="_blank">http://old.nabble.com/host-meta-and-%22acct%3A%22-tp26079872p26146197.html</a><o:p></o:p></p>
<div>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:2.0in'>Sent from the OpenID - General mailing list archive at
Nabble.com.<br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-general"
target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><o:p></o:p></p>
</div>
</div>
</div>
<p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt;
margin-left:2.0in'><br>
<br clear=all>
<br>
-- <br>
<a href="http://hi.im/santosh" target="_blank">http://hi.im/santosh</a><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt;
margin-left:1.5in'><br>
<br clear=all>
<br>
-- <br>
<a href="http://hi.im/santosh" target="_blank">http://hi.im/santosh</a><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
<p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:
12.0pt;margin-left:1.0in'><br>
<br clear=all>
<br>
-- <br>
<a href="http://hi.im/santosh">http://hi.im/santosh</a><o:p></o:p></p>
</div>
</body>
</html>