Draft OpenID v.Next Discovery working group charter

Phillip Hallam-Baker hallam at gmail.com
Thu Apr 15 05:07:47 UTC 2010


404 Not Found.

When the Web was first proposed, the thing the network hypertext
community could not get their heads around was that Tim's 'scruffy'
links were better than the database backed schemes they used to assure
consistency.

The 'unreliability' of delegation in email is both a benefit and a
problem depending on what you are trying to achieve.

When I left VeriSign my email address was disabled. But I can still
log into sites as pbaker at verisign.com as the credentials are
maintained locally. So the lack of effective federation means that an
authenticator that should fail does not.

In the context of fred at extortion.com, Fred could in theory invest a
huge amount of time and effort building up his reputation tied to a
name he does not own and then find that he has no recourse when
extortion.com raises rates on him.


This is why the question of what gives a registry of names stability
is a very complex problem. It is a very easy problem to solve if you
just wish away all the problems.

RealNames and AOL both attempted to establish naming schemes for the
online world. Both ultimately suffered from the fact that businesses
know about the fred.extortion.com problem and don't want to invest
their advertising dollars building up a name they do not own.

The only cases where these systems seem to succeed is when nobody is
really aware of the political issues that they raise. DNS succeeded
for one simple reason: it was considered to be a temporary research
facility. There were two directory schemes bid by the NSF, Network
Solutions got the tiny contract for the piddly testbed. Everyone else
was bidding for the X.500 directory where the real money was going to
be...

ICANN is easy to take pot shots at - and I do quite frequently. But
the one fact that made agreement on the ICANN charter possible was the
fact that the DNS already existed and had several million names
registered already. There was nothing to be achieved by simply
filibustering the creation process. I am seeing other registry designs
being proposed where that is not the case, and we now have governments
saying that they would rather see no registry established than one
that is under 'foreign domination'.

Simply introducing an additional layer of indirection does not solve
this particular problem. Its like cloud computing, drawing a picture
of your server running in a cloud somewhere does not mean that the
issues of physical security, power, cooling etc. can be ignored, they
still have to be dealt with by someone.


On Thu, Apr 15, 2010 at 12:37 AM, Nat Sakimura <sakimura at gmail.com> wrote:
> I suppose we need to define "OpenID identifiers" in the charter
> proposal a little more.
>
> Specifically, I would like the discovery process to find a
> non-reassignable identifier.
> Otherwise, delegation would not work reliably etc.
>
> See: http://www.sakimura.org/en/modules/wordpress/identity-loss-with-openid-20/
> for
> some additional thought/discussion.
>
> =nat
>
> On Wed, Apr 14, 2010 at 4:30 AM, Mike Jones <Michael.Jones at microsoft.com> wrote:
>> What follows is a draft charter for the OpenID v.Next Discovery working
>> group.  This is one of 5 related charters for v.Next working groups to be
>> formed to be discussed here, per my previous message.  Feedback is welcome,
>> as are potential working group participants.
>>
>>
>>
>>                                                                 -- Mike
>>
>>
>>
>> (a)  Charter.
>>
>> (i)       WG name:  OpenID v.Next Discovery.
>>
>> (ii)      Purpose:  Produce a discovery specification or family of discovery
>> specifications for OpenID v.Next that address the limitations and drawbacks
>> present in the OpenID 2.0 discovery facilities that limit OpenID’s
>> applicability, adoption, usability, privacy, and security.  Specific goals
>> are:
>>
>> ·         enable discovery for OpenID identifiers, including those utilizing
>> e-mail address syntax and those that are URLs,
>>
>> ·         enable discovery of features supported by OpenID v.Next OpenID
>> Providers and Relying Parties,
>>
>> ·         enable discovery of attributes about OpenID v.Next OPs and RPs,
>> including, but limited to visual logos and human-readable site names,
>>
>> ·         enable discovery supporting a spectrum of clients, including
>> passive clients per current usage, thin active clients, and active clients
>> with OP functionality,
>>
>> ·         enable discovery supporting authentication to and use of
>> attributes by non-browser applications,
>>
>> ·         seamlessly integrate with and complement the other OpenID v.Next
>> specifications.
>>
>>             Compatibility with OpenID 2.0 is an explicit non-goal for this
>> work.
>>
>> (iii)     Scope:  Produce a next generation OpenID discovery specification
>> or specifications, consistent with the purpose statement.
>>
>> (iv)     Proposed List of Specifications:  OpenID v.Next Discovery and
>> possibly related specifications.
>>
>> (v)      Anticipated audience or users of the work:  Implementers of OpenID
>> Providers, Relying Parties, Active Clients, and non-browser applications
>> utilizing OpenID.
>>
>> (vi)     Language in which the WG will conduct business:  English.
>>
>> (vii)    Method of work:  E-mail discussions on the working group mailing
>> list, working group conference calls, and face-to-face meetings at the
>> Internet Identity Workshop and OpenID summits.
>>
>> (viii)  Basis for determining when the work of the WG is completed:  Work
>> will not be deemed to be complete until there is a consensus that the
>> resulting protocol specification or family of specifications fulfills the
>> working group goals.  Additional proposed changes beyond that initial
>> consensus will be evaluated on the basis of whether they increase or
>> decrease consensus within the working group.  The work will be completed
>> once it is apparent that maximal consensus on the draft has been achieved,
>> consistent with the purpose and scope.
>>
>> (b)  Background Information.
>>
>> (i)       Related work being done in other WGs or organizations:  OpenID
>> Authentication 2.0 and related specifications, including Yadis 1.0.  OAuth
>> and OAuth WRAP.  XRDS, XRD, and WebFinger.
>>
>> (ii)      Proposers:
>>
>> Allen Tom, atom at yahoo-inc.com, Yahoo! (co-chair)
>>
>> Michael B. Jones, mbj at microsoft.com, Microsoft (co-chair)
>>
>> John Bradley, ve7jtb at ve7jtb.com, independent
>>
>> Additional proposers to be added here
>>
>> (iii)     Anticipated Contributions:  None.
>>
>>
>>
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>



-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/


More information about the specs mailing list