On 5/10/2010 10:07 PM, SitG Admin wrote:
I'm not understanding what you are describing.
I've failed to answer your question, then - sorry I couldn't be of more
help here.
I'm still in favor of OpenID not relying on the singularly centralized
DNS, since OpenID can only be as "decentralized" as its *most*
centralized component. (Unless there are alternatives which can replace
Then you had better also design it not to use IP or TCP or any other Internet
Standard.
In other words, the goal you've stated is not going to work, if you are diligent
and consistent in pursuing it.
As for 'centralized', perhaps you might like to review the design and operation
of the DNS in a bit deeper detail. Both registration and operation of the DNS
are highly decentralized. What is centralized is control of the contents of the
root of the tree (but not even operation of it.) It is, in fact, the largest
operational distributed service in the world.
I'm quite sure you are describing a non-existent capability.
I'm quite sure that *OpenID v.Next* is still non-existent ;p
Exactly. Designing one new thing to rely on another, unspecified new thing
doesn't work. There's plenty of experience with this problem.
Making current designs attempt to cover unspecified hypothetical
extensions is typically not successful in these efforts.
It's the chicken-and-egg dilemma: forward-compatibility. See:
http://lists.openid.net/pipermail/openid-general/2009-November/019470.html
OpenID is an authentication encapsulation protocol, *intended* to be
extensible. Does it actively *hamper* OpenID to remain open to the
possibility of future developments in an area of interest?
Extensibility is fine. It has limits. That's not a theoretical statement.
Please take a look at:
<http://bbiw.net/ietf/ietf-stds.html#StdWay30>
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
