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.<div><br></div><div>For this the original objectives of XRD and host-meta have been changed somewhere down the line. After the "acct:" scheme came up.</div>
<div>1) XRD from "descriptor" to "markup language"</div><div>2) host-meta from "simple mapper" to "extending DNS".</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>Unfortunately these guys don't seem to be in a great mood to listen to reason.</div>
<div><br><br><div class="gmail_quote">On Fri, Oct 30, 2009 at 11:51 PM, Peter Williams <span dir="ltr"><<a href="mailto:home_pw@msn.com">home_pw@msn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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>
<font 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><br>
</font></blockquote></div><br><br clear="all"><br>-- <br><a href="http://hi.im/santosh">http://hi.im/santosh</a><br><br><br>
</div>