Hmmm. So, what is your point?
On Thu, Apr 15, 2010 at 2:07 PM, Phillip Hallam-Baker <[email protected]> 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 [email protected] 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 [email protected], 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 <[email protected]> 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 <[email protected]> >> 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, [email protected], Yahoo! (co-chair) >>> >>> Michael B. Jones, [email protected], Microsoft (co-chair) >>> >>> John Bradley, [email protected], independent >>> >>> Additional proposers to be added here >>> >>> (iii) Anticipated Contributions: None. >>> >>> >>> >>> _______________________________________________ >>> specs mailing list >>> [email protected] >>> http://lists.openid.net/mailman/listinfo/openid-specs >>> >>> >> >> >> >> -- >> Nat Sakimura (=nat) >> http://www.sakimura.org/en/ >> http://twitter.com/_nat_en >> _______________________________________________ >> specs mailing list >> [email protected] >> 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 _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
