Draft OpenID v.Next Discovery working group charter

[SitG Admin]

>Then you had better also design it not to use IP or TCP or any other 
>Internet Standard.

Not all of them are centralized . . . also, note focus on "MOST centralized".

>In other words, the goal you've stated is not going to work, if you 
>are diligent and consistent in pursuing it.

Absolute security (to use an analogy) can impair utility. This 
doesn't mean we don't try to address the most egregious offenders.

Failing to address ALL aspects of insecurity (especially by dint of 
not having addressed them *yet*) does not imply a failure to address 
the most significant aspects.

>As for 'centralized', perhaps you might like to review the design 
>and operation of the DNS in a bit deeper detail.

I'm familiar with it. I know it's distributed; I don't see that as relevant.

>Exactly.  Designing one new thing to rely on another, unspecified 
>new thing doesn't work.  There's plenty of experience with this 
>problem.

I'm sure that a PHP plugin which lets arbitrary sockets connect with 
Tor, without having a separate Tor daemon running, would *not* rely 
on OpenID - it would just be awfully *useful* for it :)

Rewriting the Tor source code to be (minimally) functional in a 
server-side scripting language, instead of as a compiled binary - oh 
yes, I'm sure that *my* project wouldn't have the problem you 
describe. But it's not this specific example which is standing as the 
sole use-case, is it? There's the possibility of *any* extension 
being developed in the future:

>Please take a look at:
>
>    <http://bbiw.net/ietf/ietf-stds.html#StdWay30>

Beautifully expressed, thank you for articulating *everything that I 
have been trying to tell you* :)

-Shade