Draft OpenID v.Next Discovery working group charter

Nat Sakimura sakimura at gmail.com
Thu Apr 15 17:00:27 UTC 2010


Hmmm. So, what is your point?


On Thu, Apr 15, 2010 at 2:07 PM, Phillip Hallam-Baker <hallam at gmail.com> wrote:
> 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/
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en


More information about the specs mailing list