Draft OpenID v.Next Discovery working group charter

[Dave CROCKER]

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