user@domain URNs, independent from OpenID spec
mario at erphesfurt.de
Mon Jul 4 09:14:36 PDT 2005
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"
2) <link rel="userid-to-url"
3) <link rel="username_transform"
All the above examples have their advantages and problems.
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.
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:
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
- 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
- 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.
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
More information about the yadis