W3C home > Mailing lists > Public > www-tag@w3.org > May 2012

RE: [apps-discuss] The acct: scheme question

From: Paul E. Jones <paulej@packetizer.com>
Date: Sun, 27 May 2012 19:18:30 -0400
To: "'Henry Story'" <henry.story@bblfish.net>
Cc: "'Graham Klyne'" <GK@ninebynine.org>, "'Noah Mendelsohn'" <nrm@arcanedomain.com>, <www-tag@w3.org>, "'public-webid'" <public-webid@w3.org>
Message-ID: <011201cd3c5f$07ec2a90$17c47fb0$@packetizer.com>

Henry wrote:
> Paul Wrote:
> > WebFinger can definitely use HTTP-based URIs, too. Further, those
> > could identify people.  For example, I have my home page here:
> >
> > http://www.packetizer.com/people/paulej/
> >
> > Following your WebID example, the alternate subject name in the
> > client-side certificate might contain that ID and WebFinger could
> > certainly be configured to resolve it.  It might just be one of
> > several aliases that correspond to my account.
> Thanks for that information; I did not know that.
> I would just suggest that at that point one might as well go directly to
> dereference the
> http(s) URI,  rather than going through a slightly arbitrary intermediate
> resource.

If the identifier I have for a person was the HTTP identifier, then I would
use that.  Likewise, if the identifier I have was "paulej@packetizer.com", I
would use that.  But, when I use that form, we need a scheme.  We could use
mailto, which would work in that case.  But, what if I used the twitter ID
"paulej"?  What would be the identifier I use?

Trying to get away from requiring users to be forced to use HTTP URLs
(because we know they did not like them), we want a user@domain form.  Thus,
"acct" was born.  It is not just an arbitrary choice.  It's something that
would be consistent and predictable.  I would use "acct:paulej@twitter.com"
to refer to a twitter user.  I would use "acct:paulej@photobucket.com" to
refer to that account.  As the end user, I would not enter "acct".  The
client would accept "paulej@domain" and put "acct" on the front.  We're
trying to make the process work easily for end users, thus the desire for

All the while, there may be aliases.  In the case of Twitter and
photobucket, it might be:
http://twitter.com/#!/paulej  (I wish she would give me that ID)

Photobucket actually has will accept a URL of that form, but they also
redirect requests to various servers like s1145.photobucket.com and
s378.photobucket.com.  This is understandable, but it's quite challenging
for the typical user.

So, we need a user@domain for for the human population and we need support
for other URI schemes for automated systems where a non-techie user never
touches it (e.g., WebID). This was actually the original intent with OpenID,
too.  The intent was for paulej@packetizer.com to be mapped to

> > To your point about OpenID and HTTP URIs, you're right.  I was rather
> > put off by the fact that OpenID URIs looked so ugly.  I wrote my own
> > server and my ID is https://openid.packetizer.com/paulej/.  But, I
> > don't want to have to type that all the time.  It's rather painful.
> > This is absolutely an end-user consideration.  I understand the URI,
> > but most end users scratch their heads at it. Some end users are
> > totally confused by it.  At the same time, user@domain seems to work
> > well with the average person.  Thus, there is this desire to use
> > "mailto:paulej@packetizer.com" by the SWD folks.  That made sense from
> > a usability perspective, but it does not address how I might refer to
> > my account at a photo sharing site.  We could re-use "mailto", but it's
> just not right.
> >
> > So, "acct:paulej@packetizer.com" was an attempt to find an identifier
> > that the average person can understand and use.  They'd never type
> > "acct", just as they do not type "mailto" today, either.
> Yes, I understand the advantage of accnt, it does not necessitate the
> leaking of an e-mail address.
> I can see a lot of cases where having easy to remember addresses in that
> form can be useful, and in that case the web finger protocol shines.

Not only easy to understand, but easy for users to type.  You probably know
all-too-well that the typical user will not enter http or https. They
typically start with www. whatever.  OpenID proved that HTTP URIs will work,
but the average user is challenged.  Certainly not all, but a large number
of users have a hard time with them.  So, we have to put these in a form the
entire world can use and user@domain has proven to work well.
> On the other hand I also believe that there is no need for the user to
> need to type a URI at all when authenticating himself to a web server.
> WebID over TLS makes that unnecessary as shown in the short screen cast on
> http://webid.info/ There the user can point and click on his identity
> without having to type anything. Of course the address shown by the
> browser to the user can then be in the form of "name@domain" and indeed I
> would not be against recommending that as a good form for a Common Nane in
> the spec at http://webid.info/spec/ ( SHOULD or MAY ). This would help
> people that have WebID's for different purposes distinguish their
> certificates.

I'll have to admit that I had only heard of WebID prior to your email and
had not looked into it at all.  I liked what I saw. And with WebFinger, it
should be fairly easy to translate that ID into any other identifier the
user might own.

> > Use of "acct", though, would never preclude the use of other
> identifiers.
> great. I think we agree here.
> Btw. we have agreed for a while on the WebID mailing list that having a
> accnt:
> identifier backed by WebFinger preclude that accnt: identifier being
> placed in the Issuer Alternative Name of a WebID enabled  Certificate.

That's certainly another option.  I think any domain that would support
WebID and WebFinger could easily support either URI in order to resolve it.
Thus, it's probably not essential to put the "acct:" form into the
> The reason we have not worked it into the protocol is that currently I
> think only OpenLink Virtuoso has implemented a WebID protocol using accnt
> URLs.
> Most of us seem happy enough with just http uris, which are simpler to
> create and to dereference. But that can change if others create such Ids.

I think the real decision should be based on how users react.  In the video
you presented, I did not see a step where the user types anything.  Thus, it
is probably irrelevant what form the URI takes.  You could merrily use
"http" or "https" and the user does not know or care.  It is a system where
the typical end user is required to type in an ID that it suddenly becomes
important to look at "acct".  That does not appear to be happening with

> btw. accnt URI's don't I think strictly REFER to a user, but rather to an
> account.
> But one could perhaps bring in concepts of late binding, or others to work
> this into the WebID protocol.

Correct.  The "acct" URI just refers to the users account.  More precisely,
it refers to the link relations stored for a given URI.  It's the link
relations returned from the WebFinger query that can lead one to learn more
about the user, including one's OpenID URI, home page URI, RSS feed, photo
sharing site, or anything else.

Received on Sunday, 27 May 2012 23:19:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:45 UTC