Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL] Handle"http://user at example.com" Style Identifiers)

[David Nicol]

I think I'm on general but not on specs and I seem to have taken
some kind of role in this discussion so please CC me if appropriate;
I will respond using gmail's "reply all."

On 11/10/06, Pete Rowley <prowley at redhat.com> wrote:
> David Nicol hastily opined:
>> ...  might select OpenID as the method for authenticating people who wish to
>> be known by their URL instead of their e-mail address.
>
>  Huh? Where is this greater UCI infrastructure of which you speak? Why would
> support for email address based resolution stop it using OpenID?
>
>  --
> Pete

in the planning stages -- I want to extend my bitcard-like AIS "Authenticated
Identity Service" to offer the option of providing an OpenID identity as well
as e-mail identities registered with the AIS service, at log-in time.
AIS relies
heavily on e-mail, doing all authentication by e-mailed long tokens (so-called
"capability keys") and therefore avoids passwords beyond what it takes to
read one's e-mail.  (Comments about security implications of this will be
either ignored or refered to pgp discussion wikis)

Clients of the AIS service -- client applications that receive user identities
from AIS -- expect to be able to send e-mails to the users and have them
reach the users, after navigating user e-mail acceptance and delivery policies
such as they are.

An e-mail address can be represented as a mailto:... URL; but there isn't
at this time a way to represent the URL of a blog as an e-mail address;
therefore my suggestion some posts ago in this or a related thread
of an ugly rewriting scheme that would turn
http://davidnicol.diaryland.com/page2.html
into openid-page2.html at openid-smtp.davidnicol.diaryland.com or something
like that and force the operators of the domain to pick up the pieces, which
may also be a straw-man argumennt against, since it's too complex.

Simply allowing openID identity URLs  as identites in AIS would also work, but
would break client apps that want to e-mail to the users, which may be
just fine.

in conclusion, I think my realistic reccomendation at this time is that openID
define itself to be URLS only and not e-mail addresses.

> Why would
> support for email address based resolution stop it using OpenID?

To try to respond again, without dragging my own baggage in,
when an e-mail based SSO attempts to federate with the OpenID system,
the lack of an e-mail address is an obvious problem, meaning that the
use case (e-mail based SSO system federating with OpenID) is not
supported.

OTOH, expanding "Identity" beyond e-mail addresses certainly makes sense;
AIS could include telephone numbers, government-issued taxpayer identification
codes, fingerprints, whatever.  In this case, where a future AIS which would
be an umbrella identity service that offers SSO identity client applications
an authenticated identity of whatever sort the user chooses to present from
among whatever is in vogue at the time, OpenID would be the framework of
choice for web-page based identity.  Which is a serious argument for defining
OpenID as that part of the larger picture rather than trying to expand OpenID's
reach to include other identity systems. (at least i think it is. Pete
Rowley has
a much better grasp of formal rhetoric than me this week.)

And when an AIS client application wants an e-mail address and it gets
an identity sans at-sign, well it can just complain at that point and make the
user log in again with an e-mail address.

http://www.tipjar.com/rcgi/pink/pink is the AIS testing application, in case
anyone would like to see how AIS works.