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

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

From: Henry Story <henry.story@bblfish.net>
Date: Mon, 28 May 2012 00:16:59 +0200
Cc: Graham Klyne <GK@ninebynine.org>, Noah Mendelsohn <nrm@arcanedomain.com>, "www-tag@w3.org List" <www-tag@w3.org>, public-webid <public-webid@w3.org>
Message-Id: <9FFEC7C3-5741-44A5-BF28-94F78F6B5875@bblfish.net>
To: "Paul E. Jones" <paulej@packetizer.com>

On 27 May 2012, at 23:38, Paul E. Jones wrote:

> Henry,
> 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 

> 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.

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. 

> 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.

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.

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.

> The "acct" URI scheme would be one, though, that I could likely successfully
> use to query information about a person knowing their user ID (e.g.,
> "paulej") and domain (e.g., "packetizer.com").
> Paul
>> -----Original Message-----
>> From: Henry Story [mailto:henry.story@bblfish.net]
>> Sent: Friday, May 25, 2012 3:00 AM
>> To: Graham Klyne
>> Cc: Noah Mendelsohn; www-tag@w3.org; paulej@packetizer.com
>> Subject: Re: [apps-discuss] The acct: scheme question
>> On 24 May 2012, at 20:55, Graham Klyne wrote:
>>> On 23/05/2012 16:35, Henry Story wrote:
>>>> On 23 May 2012, at 17:19, Noah Mendelsohn wrote:
>>>>> Of possible interest to the TAG: this is being discussed on the apps-
>> discuss mailing list, where there is a long thread. Note specifically the
>> discussion of a proposed "acct" URI scheme "to identify individuals".
>>>> There cannot be only one scheme to identify individuals. You can do
>>>> it with http, https, ftp, ftps, and many other ways. The folks should
>>>> stick to stating their claims in general terms: "a URI that identifies
>> an agent of some kind", without tying themselves to one in particular.
>>> Just to be clear... they are *not* tying themselves to a particular
>> scheme. That's been stated quite emphatically.
>>> The uncompelling aspect of their proposal, as I see it, is that it's
>> hard to see what distinct purpose is served by the proposed acct: scheme
>> that can't easily be handled by another scheme.  But it seems there are
>> strong "social" pressures (and maybe operational - I can't tell based on
>> my limited knowledge of the context) to have something that is distinct
>> from specific applications/protocols to have a way of finding information
>> accounts without their "own" URI shceme.
>>> From a pure technical perspective, I think it's fairly clear that
>> another scheme *could* be used, say http:, but I can't quite quite figure
>> why that's considered unacceptable.
>> Here is my experience with people who get really excited about accnt:
>> schemes:
>>  1. They tend to come from OpenID, which tried http:// identifiers ,
>> which people tended
>>    to find to difficult to use (and if one remove the need for http://,
>> it became impossible to
>>    distinguish http and https
>>  2. email like identifiers they found - quite reasonably - are easier for
>> people to remember
>>     because it tends to be name@org
>>  3. From this they conclude falsely that all identifiers have to be easy
>> to remember
>>   I say falsely, because as it happens with WebID the user never has to
>> type in a URI in any box at all ( see my scene cast presentation at the
>> W3C Identity in the Browser workshop last year
>>   http://bblfish.net/blog/2011/05/25/ ), he just has to click on a
>> certificate selection box.
>>   The accnt scheme is resolvable because it is tied to the the WebFinger
>> protocol btw, which is used for example by Google and Diaspora. It is
>> reasonable to allow it, if one can also use https identifiers too.
>> The semantics of the field that accepts them ( probably called ID ) will
>> be a bit tricky, because I think accnt URIs refer to accounts, and not to
>> People. So the Identity field would have to say: a URI referring to
>> something that is well known to identify an Agent in a well known way. You
>> can't just use the reference relation.
>> 	Henry
>>    Henry
>>> #g
>>> --
>> Social Web Architect
>> http://bblfish.net/

Social Web Architect
Received on Sunday, 27 May 2012 22:17:36 UTC

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