user@domain URNs, independent from OpenID spec

[Mario Salzer]

OpenID as it stands now verifies homepage addresses and
expects sites to use that as user identifiers. This may
be all fine and sufficient in the blog world and comment
forms, but won't lead to widespread use elsewhere.

As other people have noted earlier, the only meaningful
syntax for average users are "user at domain" identifiers.
Therefore I'd like to make a proposal, which can be used
with or without OpenID and would be just a second means
to make an URL from whatever the user entered.

- Like also concluded in the earlier discussions, of
   course many many many people will confuse user at domain
   IDs with email addresses initially (especially people
   who cannot tell "the Internet" from the Web, or discern
   discussion boards from forums). This problem however
   clears itself after some education or the second failed
   attempt to send mails to there.

- It is the most intuitive syntax, and that's the reason
   this topic comes up on this mailing list that often
   (...until it gets accepted).

- Expanding "user at example.com" into an URL is not much
   worse than the address bar magic that the specification
   requires for strings like "www.example.com".

- The finally resolved URL could be used in conjunction
   with bare HTML (intermediate) pages or resolve directly
   to vCards, FOAF, or ... files.

- Fully optional as far as OpenID is concerned. Didn't
   even had to be mentioned there. It is up to web sites
   to support it or not.

There is no need for any complicated and slow XML mapping
format or hard-wired URL and path schemes, like they came
up in former discussions.
IMO it would already suffice to embed a single rewriting
hint into a web sites front page; most likely in a <link>
or <meta> tag. Consumers would only look this up if a user
entered something with an @ inside, instead of a full URL
or host name.

The actual rel= or name= identifier is probably not all too
important - we just had to agree on a sounding name and a
useful syntax and then stick with it:

  1) <meta name="userid.regex"
         content="s/(\w+)@(.+)/http:\/\/$2\/user.cgi?=$1/;">

  2) <link rel="userid-to-url"
         href="http://www.example.com/cgi-bin/user.pl?id=" >

  3) <link rel="username_transform"
         href="http://%s.hoster.com.test/" >

All the above examples have their advantages and problems.

  1) REGEX
     Was feasible even with JavaScript, but looks a bit
     like overkill even if it was the most flexible format.
     (The @content format being fixed to "s/.../.../;")

  2) URL PREFIX
     Is the simplest possible syntax, and would probably
     operate with redirects and/or intermediate HTML pages.

  3) PLACEHOLDER
     Is the simpler alternative to regular expressions,
     and would make HTTP redirects unnecessary because user
     names could be injected into domain names again.
     (%s or $1 as placeholders would be most familiar.)

Ok, this is just a rough idea, but I hope it shows that
user at domain names would require nothing more than a single
(but cache able) lookup for the transformation prefix/regex
from a single HTML page. This restricted usage to one user
system/database per domain, but that's pretty similar to
what SMTP can accomplish at most ;)

My personal preference is #3 with "%s" as placeholder, but
I'm totally unsure which rel= name would look best:
  - "userid"
  - "userid.url"
  - "userid.transform"
  - "users"
  - "userid.url-pattern"
  - "userid.substitution"
  - "user.url"
  - "user-url"
  - "site.users"
  - "userid.convert"
  - ...

Maybe we here can agree on one of the possible syntaxes
and a name for it. It is definitely worth the time
considering it, given that the final URL could point to
just a HTML page for OpenID use, but also indirectly to
FOAF/vCard/xCard/... user profiles. Additionally such a
scheme could be used and expanded into other systems (LID)
once agreed upon.


And a few more notes:

- I'd outright object the name for such a <link> or <meta>
   entry becoming "openid.*" - I want to have such an
   agreement fully independent from OpenID, and also fully
   independent from any specific profile or data format (at
   the URL endpoint). Though, I admit, I need this for my
   own pet project.

- The user at domain syntax is far more sounding not only to
   users, but probably also in the context OpenID was meant
   to be used:

   - "Message posted by bob.livejournal.com" may not read
     all too weird yet (optically+semantically), but

   - "Message from http://some.com/~strange/url.htm" is what
     would inevitably happen

   - "Comment written by jane at way.com" is in any case more
     senseful

- The so called "URL canonicalization" from the spec is
   meant to allow displaying the above "bob.livejournal.com"
   abbreviations,  but happens to work for site setups like
   that from LJ only - many people will get/see ugly URLs -
   even without the leading http:// (which crowns host names
   to URLs).

- Danger of confusion with email addresses is an extremely
   weak point, especially if clicking on "user at example.com"
   wouldn't bring up an email client, but linked to the URL
   endpoint (a user profile/info page most likely) instead.
   Much like "user.livejournal.com" would underly a real
   href to a web page.

Btw,
all belittling statements in this mail are meant to give
a second view onto the use of URLs in OpenID, not to start
a flamewar here on the user.provider.com vs. user at domain
syntax.