On Thu, 2010-07-22 at 14:06 +0300, Toni Stoev wrote: > > I don't think the latter is very realistic. On the application > layer, > > sure, you can have any number of identity providers. But I don't > think > > it is likely that you will have a supplier of a network identifier > that > > is not your connectivity provider. > > It would not be compulsory to have one, but if you would have the > possibility to choose a remote network identity provider, your privacy > would have more of a chance. > And choice is the advantage of the popular dynamic DNS service > providers. > > > Sure, I can imagine a world in which > > TOR like companies will emerge that provide some sort of proxy and > that > > promise to keep your identity secret, but if you want to do that any > any > > significant scale you will run into problems. Let's not create a > design > > that forces us 10 years down the road to solve the GUPI-PII (global > > unique persistent identifier - person identifiable information) > > problem...... I am all for incremental design, but having a tight > > coupling between humans and persistent identifiers is asking for > trouble > > imo. > > I agree.
Perhaps I'm missing the point, or missunderstanding something. But isn't this, in the FQDN case, trivial? Use some dynamic dns service which mapps an arbitrary name to your IP. Result, no worse than today. Much as some people prefer to use an DNS server not provided by their ISP, one may use a name provider that is not their ISP. a. Register name (FQDN) "secret123.freenameprovier.org". b. Update my name to my IP. c. Use your new the ID->Loc association d. Unregister the name , or just let the name expire. // Javier
signature.asc
Description: This is a digitally signed message part
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
