<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";}
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;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@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>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I’m not yet convinced in the “host” axiom of
the host-meta arrangement, either. But, it’s for a different reason to
that you proffer.<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'>For me, it seems to deny what the semweb claims about a uri
being able to refer to anything (that metadata at the URI written using the rdf
metamodel will then describe). This is something the W3C TAG are going to note
(and presumably comment on to IAB). We don’t want the very same argument
presented against XRI (the web can do it natively; don’t bother) to be
used against such as the XRD host-meta profile (the semweb can do it natively; don’t
bother). <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'>Arguably, the foaf+ssl experiment – being built according
to pure semweb theory - is showing W3C folks that perhaps semweb principles
with https MAY be able do exactly what XRD and host-meta are claiming to do (without
requiring the host axiom or the XML of XRD).<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'>But let’s take it as a given that a uri cannot “really”
identify the concept known as a “host”. Lets then accept the proposal
that one can exploit the well-known url-factory rules (per profile of XRD) that
trivially rewrites domain names string about hosts into http URI identifiers, for
metadata of that metadata type. And lets assume DNS can confirm that the domain
name is a “governed” host, furthermore (using trusted DNS).<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'>Providing there exists a mean (e.g. https and server certs making
domain-control assertions) to confirm that the host-meta file is bound to the
domain name of the host, now let the RP use the link rule from the recovered
document to obtain further XRD metadata for each user (but only “validly”
for those users specified in the scope rules). <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'>Perhaps consider that the context that MIGHT be played by an
issuing authority populating xrd.subject field could be being played by the
https server (and its domain cert). In some sense, the subject field is implied
by what the socket the RP uses reports, as it confirms the identity of the server
“host” its talking to (using ssl’s record layer). Being
context free, one gets the loose coupling of files and domains, making for easier
management and provisioning by lots of parties using 80:20 management culture.<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'>Of course, an SSL server X.509 cert or X.509 PAC COULD specify
the scope rules (and then the link template) that is present in the XRD. One
form of metadata is just as good as another, and a cert is just metadata about
a domain name these days. If one wanted, one could be dynamically stuffing the
XRD host-meta stream in an __ephemeral__ SSL server cert delivered when talking
https. Just put the XRD into that cert’s extension, signed on the fly by
the SSL ciphersuite.<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'><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'><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:.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"'> Santosh Rajan [mailto:santrajan@gmail.com] <br>
<b>Sent:</b> Sunday, October 25, 2009 9:36 PM<br>
<b>To:</b> Peter Williams<br>
<b>Cc:</b> general@openid.net<br>
<b>Subject:</b> Re: [OpenID] Comment on new Draft host-meta<o:p></o:p></span></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoNormal style='margin-left:.5in'><span class=apple-style-span><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Peter,<o:p></o:p></span></span></p>
<div>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.0pt;
font-family:"Arial","sans-serif"'>The purpose of the host-meta is to provide a
mapping for the URI's (read Subject) of the XRD, to its actual location for
retrieval. For doing this all you need is the "http" scheme for the
host-meta.</span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.0pt;
font-family:"Arial","sans-serif"'><o:p> </o:p></span></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.0pt;
font-family:"Arial","sans-serif"'>The hilarious part of the whole thing is
that, after jumping through all the hoops of the "DNS scheme
extension", what actually retrieves the XRD (URI Template) is your good
old "http" scheme.<o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.0pt;
font-family:"Arial","sans-serif"'><o:p> </o:p></span></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>On Mon, Oct 26, 2009 at 2:51 AM,
Peter Williams <<a href="mailto:home_pw@msn.com">home_pw@msn.com</a>>
wrote:<o:p></o:p></p>
<p class=MsoNormal style='margin-left:.5in'><br>
If I were designing a set of tags that could serve multiple world of (i)<br>
"identity authorities" issuing identifiers, and (ii) "resource
authorities"<br>
issuing (resource) identifiers, Id make sure it was flexible enough for that<br>
purpose.<br>
<br>
Perhaps we consider the xrd.subject issue in that light. (it works for me,<br>
down here in ignorance land).<br>
<br>
subjects are more aligned wth that use of XRD we are most familiar with<br>
(from the world of XRI): identity naming, by registries.<br>
<br>
In the contrasting world of resource authorities, the xrd.subject is less<br>
germane.<br>
<br>
Now, what we know (from the explanation Dirk gave here several months ago<br>
when announcing Googles OPs-for-domains initiative) is that there is a<br>
strange cross-over: between identity authorities and resource authorities.<br>
This occurs when one is is consider the OP-for-domains delegation issue set<br>
specifically: when can one domain's endpoints speak for the users at<br>
another? when can one locator service for metadata at domain X be an<br>
_authoritative_ source of metadata about URIs who authority domains are<br>
other than X?<br>
<br>
If we view the host-meta use of scopes AND a URI-template in light of that<br>
discovery problem (addresing the authority of a metadata locator service to<br>
speak for identified users at another domain), perhaps its less hard to see<br>
the design motivations of the profile.<br>
<br>
Its now no longer about a syntax issue: the rights and wrongs of tag and<br>
field design in a generic format. Rather, its an application of the tools<br>
provided by the XRD format (when extended by IETF) to let one domain speak<br>
for another, and one set of URI to be authoritatively served/represented by<br>
a provider at another URI.<br>
<br>
So one doesnt have to enumerate all the users at the google apps domain X,<br>
when the cloud service provider is doing offloaded work for n users for the<br>
apps-domain X, use a scope... which implicitely defines the parties it<br>
speaks for. Have multiple scopes, when there is (XRI-like) a delegation
of<br>
authority matter going on (during a corporate takeover , say).<br>
<br>
what is nice is that the XRD recovered for a hosted domain or a hosted user<br>
is still available to the RP (once recovered using the URI factory in the<br>
URI template, and the metadata server. . That users XRD may (now that its<br>
been located and recovered) not actually point to the cloud hosting point.<br>
<br>
Now, I do thing that there is a certainly * going on (I cannot decide on the<br>
word *). Though architecturally, the user XRD's links might point elsewhere,<br>
those user XRD are provisioned by parties other than the user. SO, Im not<br>
convinced the theory of user-centric control will be realized (any more than<br>
at myopenid, where the provider does NOT allow you control your user-level<br>
XRD, enabling *user-selected* domain delegation). Yes you the web-rights<br>
theoretically, but not in "reality".<br>
<br>
What Im noting, compared to the threads n this months ago, is _is_ getting<br>
clearer.... And,... it IS being handled in repsected standards forums where<br>
lots of folks with lots of agendas get to argue the merits. It all looks<br>
pretty open... by normal measures of community standards making.<br>
<br>
Peter.<o:p></o:p></p>
<div>
<div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<br>
<br>
<br>
Santosh Rajan wrote:<br>
><br>
> Quoting from<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>
> "host-meta document SHOULD NOT include the 'Subject' or 'Alias' XRD<br>
> elements since these elements require a valid URI to identify
the<br>
> resource being described, which is not available for the
host-meta<br>
> scope."<br>
><br>
><br>
> Yet you have taken the very same URI's, that should have been in the<br>
> Subject<br>
> and Alias fields to begin with, split them into scheme and authority,<br>
> stuck<br>
> them into a new "Scope" element and embelished it with a new
namespace to<br>
> give it more legitimacy. Logically i dont see any difference from using<br>
> the<br>
> Subject and Alias.<br>
><br>
><br>
> "not available for the host-meta scope" is very different from
"not<br>
> available for the host-meta". You cannot justify ignoring the Subject
of<br>
> the<br>
> XRD, based on its "Scope". The Subject of an XRD is about the
XRD itself<br>
> and<br>
> not its scope.<br>
><br>
><br>
> The host-meta is not some "Thing" that resides in somebody's
backyard, so<br>
> that it cannot have a URI to identify it. As for differentiating the<br>
> host-meta from the actual URL resource, haven't we already done it with<br>
> the<br>
> ".well-known" path? There is no valid justification to ignore
the Subject<br>
> here.<br>
><br>
><br>
> As for your use of "authority", i see a couple of problems using
it.<br>
> 1) "authority" has a "userinfo" part that will break
your usage of it in<br>
> this context.<br>
> 2) URN's do not have a authority part. scheme="acct",<br>
> authority="<a href="http://yahoo.com" target="_blank">yahoo.com</a>"<br>
> is meaning less.<br>
><br>
> --<br>
> <a href="http://hi.im/santosh" target="_blank">http://hi.im/santosh</a><br>
><o:p></o:p></p>
</div>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>>
_______________________________________________<br>
> general mailing list<br>
> <a href="mailto:general@lists.openid.net">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>
><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>> -----<br>
><br>
> Santosh Rajan<br>
> <a href="http://santrajan.blogspot.com" target="_blank">http://santrajan.blogspot.com</a><br>
><br>
<br>
--<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'>View this message in context: <a
href="http://www.nabble.com/Comment-on-new-Draft-host-meta-tp26036844p26051937.html"
target="_blank">http://www.nabble.com/Comment-on-new-Draft-host-meta-tp26036844p26051937.html</a><o:p></o:p></p>
<div>
<div>
<p class=MsoNormal style='margin-left:.5in'>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">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:0in;margin-right:0in;margin-bottom:
12.0pt;margin-left:.5in'><br>
<br clear=all>
<br>
-- <br>
<a href="http://hi.im/santosh">http://hi.im/santosh</a><br>
<br>
<o:p></o:p></p>
</div>
</body>
</html>