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/ _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
