<div class="gmail_quote">On Mon, Jun 7, 2010 at 9:19 PM, Phillip Hallam-Baker <span dir="ltr"><<a href="mailto:hallam@gmail.com">hallam@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
As often happens in these debates, we have a proposal that has an<br>
acknowledged issue that we are being told isn't an issue because the<br>
developers don't see it as an issue.<br>
<br></blockquote><div><br></div><div>Actually, what's happening is that people are re-raising objections that were discussed back in April and ignoring the answers that were given then. It's fine to disagree with the answers, but it's polite to acknowledge that answers have been given and, ideally, attempt to refute them instead of pretending the answers don't exist.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I really take offense when I raise an issue and someone says 'that<br>
does not matter to anyone' or 'that issue has been dealt with'. The<br>
one issue that I have never found it difficult to get the industry to<br>
agree on is the necessity of ensuring that no party gains a<br>
proprietary leverage in a communication protocol.<br></blockquote><div><br></div><div>Please read the blog posts. It's very difficult to even discover what different people consider to be "the problem". Shouting "privacy!" doesn't actually move the discussion forward. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
I don't see how the promise that the issue will be fixed in future<br>
changes anything. Either the centralization is easy to eliminate from<br>
the protocol or it isn't. And if it is easy to eliminate then why<br>
introduce it in the first place?<br></blockquote><div><br></div><div>Pleaser read the blog posts; I think I've explained the reasoning in fair detail. It is easy to eliminate once you convince browser vendors to do so; a world where XAuth is already widely deployed is much more conducive to doing this than one where it is not.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
The starting point for identity in my view is that I have to entirely<br>
own my name. There cannot be any entity that can use the investment I<br>
make in my name to extract rent at a future date. No corporation, no<br>
not-for-profit, no non-profit, no industry group. Nothing.<br>
<br></blockquote><div>Then you are going to be running your own IdP, and you need not opt in to XAuth. Problem solved.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The reason I tolerate DNS is that the operation of the DNS does not<br>
depend on a single entity regardless of what ICANN might try to get<br>
you to believe because ICANN does not have control over the country<br>
code domains. Some of the country code domains still refuse to pay the<br>
scutage demanded by ICANN for inclusion in the root.<br>
<br>
ICANN is tolerable because the various components are sufficiently<br>
independent and sufficiently loosely bound that if push comes to shove<br>
and ICANN was to attempt to defect, the entire stack of cards would<br>
collapse. The root would fracture. That is not a property that any of<br>
the proposed alternatives have.<br>
<br>
<br>
The names that the users want to use are <a href="mailto:username@domain.name">username@domain.name</a><br>
<br>
There is no need for any discovery infrastructure other than the DNS<br>
to resolve such names and no application discovery infrastructure<br>
offers the same technical capabilities such as failover through SRV<br>
records as the DNS does.<br>
<br>
But we keep coming back to this model because driving traffic through<br>
a central node creates business models for the party controlling that<br>
node that the VC community thinks they understand.<br>
</blockquote></div><br><div>Since there is ~no traffic going through <a href="http://xauth.org">xauth.org</a> in any of the implementations, I'm not clear how this is relevant.</div>