<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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{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;}
/* List Definitions */
@list l0
{mso-list-id:1534807372;
mso-list-type:hybrid;
mso-list-template-ids:-1407442170 -1996554474 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:4;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</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'>Yes, the first draft of the I-D needs a good rewrite. The
writing style is hurting its mission, particularly in IETF where the technical
writing is itself a premium marker of what might make it to internet standards
status (one day). But, it’s only draft #1 - to be fair to the author!<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 got rather long. Speed read, and don’t waste more
than 2 minutes on it.<o:p></o:p></span></p>
<div style='mso-element:para-border-div;border:none;border-bottom:solid windowtext 1.0pt;
padding:0in 0in 1.0pt 0in'>
<p class=MsoNormal style='border:none;padding:0in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p>
</div>
<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 also went through a moment when I thought: hmm, if one is really
going to focus on domains (and domain-names), does it really make sense to put
the metadata in a file (rather than add RRs to DNS)? The answer was yes, on the
merits (and given the successful takeup of .crt file for certs, stored on
webservers).<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=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Adding RRs to DNS will probably take a decade of work. What
sensible business community would want to wait that long?<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Putting a file on a host, written in XML and located by
domain-name, is easy and scales to the size that DNS scale to<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Any admin can write a file on a web server on a well known
URI, as can simple wizards that provision an app-domain by default (similar to
how ISP’s auto-provision web farm tenants, located by host-header)<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>What admins do today in HTML to stuff 5 meta links with link attributes
in the HTML header, they can do in XML (in an largely equivalent markup).
Yes, one has to ask: why not use RDFa for that? The answer is probably: compatibility
in spirit with openid legacy and easier upgradability of existing libs at RPs -
that don’t need a full RDFa parser<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>What openid has already done with meta links in HTML and meta
links in XRD file for OP providers and their users’ XRDs evidently works,
and worked for openid adoption this far. Don’t fix what aint broken.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>It’s all, quite properly, a standardization of what
myopenid did already using various adhoc mechanisms, in their “for
domains” rollout model. Now everyone benefits from the standardization of
techniques. This is openness for all to see.<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'>The thing that has really happened is innovation around the “google
apps for domains” delegation, in which one domain can speak for another –
enabling a cloud provider to deliver OP or RP services in the name of its
app-domain. <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'>Beyond merely expressing the delegation between names in two administrative
regions, one then has the issue of: how does the RP know its authoritative? We could
wax lyrical how X.500 1993 standard solved this classical identifier/domains properly
in DN space (allowing for the likes of ou group policy and federated trusts
between transitive or mapped domains in Active Directory), but that all irrelevant.
Here its all motivated by the topics of directed identity and law #4 semantics,
which introduces locator and identifier semantics that simply require more
involved validation logics than simple meta link resolution offers.<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'>As the nature of being an OP means typically serving per user
XRDs, one has the issue of pointing at the URI where as cloud provider one
serves up the user XRDS “in the name of any one of 10 million app-domains”;
ensuring the RP can tell which user XRDs authoritatively belong to which one of
the 10 million hosted app domains. <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 don’t think one can pull out the user XRD locator from
the app-domain scoping, or pull out the cloud outsourcing of app-domains from
the user XRD locating, or the attributed linking from the design of the markup.
They all go together, to address the above. Standards are about standardization,
and that’s what its clearly doing.<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'>As much as folks want to say the XRD1.0 is fundamentally
different from the XRD we all used in the YADIS period, it isn’t. It is
simply being unbunded from http and XRI identifiers, and the SEP-style markup
updated to now align in markup concept with http meta links (learning from
atom).<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'>Calling an XRD a descriptor does not worry me. that’s just
of bit of standard abstract metadata-speak. It’s a magic word, consistent
with using conventions in English when talking in and about metamodels. Using formal
Spanish would do better than using English for this - since one has the latinate
structure to make internal lots of references within long 200 word, multi-clause
sentences. But, its being written in English, which uses conventions, instead. Once
you get used to the magic words, its short and snappy. Pick your evil: extended
latin grammar like Newton used for the laws of physics in the 1670s , or subtle
conventions for the laws of identity, in 2010.<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'>Yes I sometimes wish the metamodel was as consistent as it was
in the XRI days ( a descriptor is metadata about an identifier), but it’s
not; so there. In the case of host-meta, I find myself believing (though it only
partly says it): its “about” an domain-name – obviously an identifier.
If the author could just say what he means, rather than be so abstract!<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'>Is one “extending DNS” by referring to a file on a web
server located having used DNS to resolve the authority component of a URI
scheme when it treated as and infact IS a domain name? No. One does the same
thing in X.509 .crt files stored on web servers, whose DNs are indexes in a
directory. IETF already standardized the latter, in some PKI RFC whose number
changes every few years. The world of NATO directories with its 300 page
standard for domain delegation within the DN-centric DIT and multi-schema
metadata distribution within “autonomous policy regions” in a DIB
…didn’t collapse, and infact didn’t even blink. The internet
just went around ISO, in 3 paragraphs, and stuffed an X.509 cert in a file on a
webserver, where the file is located by domain in a http URL. Ditto for crl
files, trust anchors, and trust chains.<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'>If one failed to put a subject DN in an X.509 cert persisted to
a .crt file locatable on a well known http URI on some domain’s
webservers, and one then put 5 subject alt names in that structure each using
the URI name form (now playing the role of 5 links in an XRD and even a URI “template”)
would the missing subject DN matter to the semantics of X.509? 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>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Does a cert in a .crt file already have a “scheme mapping”
notion? Yes. Its called the “alt names” construct for subjects (and
issuers). No patent claims there. Though, its clearer in the host-meta
conception (I think).<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'>Does a cert in a .crt file already have the notion that URI scheme
“authorities” have jurisdictions, and can be tied of “domains”
– that “govern” _<i>authorities</i>_. Yes. It’s called
the cn=<domain> field (circa 1995) and the more modern conventions that
place a list of domain names in an subject alt name. No patent claims there;
the cert as metadata (stuffed in a file with a well-known file extension,
stored on a webserver locatable by http URL) already did it. No patent or PhD originality
claim for that non-invention.<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'>If one buys into all this (and one views signed XRD
much as a modern signed cert with a change of format from ASN.1 to XML), then
one might as well work within its framework. Might as well now use its expressions
to address, per domain (on a “host” basis) and for each app-domain:
how to enable sreg <i>and ax attributes </i>to be described using additional
metadata - hanging off the host-meta links. Then one gets to make meta-statements
about sreg and ax attributes, when treating them as “claims”, that in
turn drive claim-based identity systems.<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'>And there is the rub. This is all a web2.0 style way of doing
what VeriSIgn/IBM/Microsoft already did with ws-security following in the OSI styles
and traditions of ECMA’s ROS and related security standards (and web3.0
folks are now starting doing with secured and trusted semweb metadata built using
RESTful style). <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'>So what’s new….? There are multiple standards to
choose from, each doing the same thing! Little has changed in 25+ years, except
that its all now real (vs paper) and only getting bigger and bigger. As one
scale up, the engineering has to re-scale with it. Lots of standards politics
will be present, as each group tries to win. As always , folks will apply
rhetoric and argumentation, to help make their case.<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>
<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>
<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> Friday, October 30, 2009 8:45 PM<br>
<b>To:</b> Peter Williams<br>
<b>Cc:</b> general@openid.net<br>
<b>Subject:</b> Re: [OpenID] extending host-meta beyond IETF extensions;
ws-security policy like rules<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'>The more I look at it, the more I
can see that this whole "Scope" story is a can (truckload?) of worms
waiting to be opened.<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>For this the original objectives of
XRD and host-meta have been changed somewhere down the line. After the
"acct:" scheme came up.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>1) XRD from "descriptor"
to "markup language"<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>2) host-meta from "simple
mapper" to "extending DNS".<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>My suggestion is that we stick to
the original objectives for "Version 1.0" of XRD and host-meta spec,
and use only the "http(s) scheme, and get this whole thing working in the
first place (acct: can be used to describe an email like identifier in the
Subject). Adding "Scope" and extending DNS etc can be done in a later
Version of the spec.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>And this is not my idea. On the
webfinger list, somebody from (IETF I think) has suggested the same thing. That
they develop a simple Version 1 to start with.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>Unfortunately these guys don't seem
to be in a great mood to listen to reason.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:
12.0pt;margin-left:.5in'><o:p> </o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>On Fri, Oct 30, 2009 at 11:51 PM,
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 one buys into host-meta, using scopes to indentity for which URI (user)<br>
identifies this host is authoritative (particularly in world where cloud<br>
providers on 1 domain supports app-domains on other domains) I can see
more<br>
scope rules being required.<br>
<br>
On an app-domain basis, and then a per-user basis, each overriding the cloud<br>
providers scope, host-meta scopre for "authoritative sreg attributes"
might<br>
be added to the app-domain's host-meta file.<br>
<br>
The RP might want to know which attibutes the app-domain has
"verified", and<br>
speaks for (above and beyond the cloud provider merely forwarding the values<br>
from the users profile).<br>
<br>
Despite having outsourced to google discovery and per-user profile<br>
management for my app domain on my domain's URI, I app domain assert that I<br>
legallty represent the value of sreg.website to be in compliance with my<br>
posted policy (also hanging off of my app domains host-meta).<br>
<br>
In all likelihood, this day and age, the policy would be an RDFa document,<br>
so its readable by hiumans amd the machie-readable elements can express<br>
rules in an algerab not dissimialr to ws-securitypocliy (controlling which<br>
claims are required at which RPs, and which an IDP (i.e. app-domain, not<br>
cloud provider) is itself will to vouch for, legally.<br>
<span style='color:#888888'>--<br>
View this message in context: <a
href="http://old.nabble.com/extending-host-meta-beyond-IETF-extensions--ws-security-policy-like-rules-tp26134827p26134827.html"
target="_blank">http://old.nabble.com/extending-host-meta-beyond-IETF-extensions--ws-security-policy-like-rules-tp26134827p26134827.html</a><br>
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></span><o:p></o:p></p>
</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>
</div>
</body>
</html>