On 12/12/2015 12:30 PM, Steve Atkins wrote:
My point is that the fact that an address is unique and is heavily used
for regular interaction, makes it an identifier.
There have been various efforts to create 'permanent' identifiers that
are independent of email addresses, or the like. None has succeeded. I
believe ISP market pressures were irrelevant to those failures.
Your cellphone number, your facebook GUID and, to a
lesser degree, your twitter name are used as identifiers (and so also
1. Phone number: in theoretical terms it works as an identifier.
However there have been attempts to get it used as an alternative to an
email address and there's been no traction. The string has two strikes
against it. First, it's not human friendly, compared with a string that
has sematnics. Second, people don't see or use it all that often. (I
suppose these days, given email UI design, the same could be said for an
email address... mumble.) And BTW, phone number only sometimes -- maybe
even often, but not always -- maps to a specific individual...
2. Facebook, google, etc. identifiers. These are independent
namespaces, but ultimately translate into an email address. The
invocation character (hash, at-sign, whatever, replaces the
@<service-provider>.com string. I'm not quibbling here. These really
are alternate encodings for the same construct.
authentication) in a lot of places. For many services your facebook
GUID or cellphone number is preferred, and use of an email address
as identity may not be supported in MVP (or in some cases, at all).
I'm not sure the security uses of these qualify as 'identifier' rather
than getting used for a confirmation exchange, which means using them as
an address.
It's possible to create a unique identifier without any checking for
uniqueness - you could use a type 4 GUID, for instance. Not terribly
memorable, though, so unless you want to require people to carry
Exactly. Usability is an essential feature. Email addresses seem to
strike a reasonable balance in that regard, absent left-hand-side
conventions at a provider that gives you a serial number.
If you want an identifier that is globally unique and federated then
you need some part of the identifier to be a unique identifier for
the identity provider you use, along with some additional informatio"
per identity provider to guarantee uniqueness within that identity
provider. (e.g. OpenID, which uses DNS hierarchy to create IDs).
"identity provider" that is independent of a regular service provider is
an excercise that's been attempted a few time. None got traction.
Maybe openid will. Heh.
Any federated identity system is going to have all the portability
disadvantages
email has, as well as some additional ones.
Yeah, like maintaining synchrony with an adddress...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp