[PROPOSAL] Handle "http://user at example.com" Style Identifiers

[David Fuelling]

Phillip,

Ok, now I understand what you're saying about "not using Http in this way".

However, I'm not advocating doing anything with the username part of an
email (this might be where we're missing each other).  I'm saying that we
just take the <domain> + <tld> of an email, normalize it per the OpenId
spec, and use that Http URL that we get as the URL of our IdP.   

Let me elaborate.

In a previous message, you wrote:

> > > There are two issues here:
> > >
> > > 1) The user presentation of the identifier
> > > 2) The machine presentation
> > >
> > > The two do not need to be the same. www.cnn.com works
> > perfectly well
> > > as a way to locate CNN. That is a perfectly acceptable user
> > > presentation. It is not an acceptable machine presentation and
> > > browsers SHOULD NOT accept href="www.cnn.com".

If the "user presentation" value is an email (e.g., 'beth at example.com'),
then what is wrong with the machine presentation (wrt OpenId) being
'http://example.com'?

The OpenId spec is already doing this with URL's in section 8.2
(Normalization).  We're mapping/normalizing 'www.cnn.com' to
'http://www.cnn.com', even though www.cnn.com is not (technically) a validly
schemed Http url.  Why not do the same with email addresses?

> -----Original Message-----
> From: Hallam-Baker, Phillip [mailto:pbaker at verisign.com]
> Sent: Wednesday, November 08, 2006 4:37 PM
> To: David Fuelling
> Cc: specs at openid.net; general at openid.net
> Subject: RE: [PROPOSAL] Handle "http://user@example.com" Style Identifiers
> 
> Please don't map to Http this way.
> 
> It would be fine to define a fixed mapping from a user identifier to http.
> But it has to respect the http scheme design and be crafted to avoid
> operability concerns.
> 
> http://example.com/user would be acceptable as meeting the scheme design.
> It is absolutely critical to maintain left/right hierarchy.
> 
> The username/password pieces in http were not well thought out and may
> have to be eliminated.