W3C home > Mailing lists > Public > public-rww@w3.org > June 2012

Re: Registration of acct: as a URI scheme has been requested

From: Henry Story <henry.story@bblfish.net>
Date: Sat, 23 Jun 2012 15:38:11 +0200
Cc: nathan@webr3.org, Kingsley Idehen <kidehen@openlinksw.com>, www-tag@w3.org, Melvin Carvalho <melvincarvalho@gmail.com>, Read-Write-Web <public-rww@w3.org>
Message-Id: <6B2A8507-BDB2-4972-8BF1-3778F3A33B63@bblfish.net>
To: Michiel de Jong <michiel@unhosted.org>
[ a couple of typos fixed. sorry]
On 23 Jun 2012, at 14:59, Michiel de Jong wrote:

> On Sat, Jun 23, 2012 at 2:32 PM, Nathan <nathan@webr3.org> wrote:
>> Michiel de Jong wrote:
>>> It's a premise of webfinger that we resolve a human-memorable string
>>> of the form 'user@host' to accounts.
>> 
>> I understand that, but don't see any need for a acct: URI scheme to
>> accomplish that.
>> 
>> This is a URI that will accomplish the task:
>> 
>> https://gmail.com/.well-known/host-meta?resource=joe@gmail.com
>> 
>> So where's the need for acct: ?
>> 
>> This is not two URIs, it's one URI, and no better than the above in any way:
>> 
>> https://gmail.com/.well-known/host-meta?resource=acct:joe@gmail.com
>> 
>> Thus, I conclude that the only reason to have acct: and to strap it to
>> joe@gmail.com is to use it as an identifier for an account, when that
>> account already has a perfectly good, stable over time, but not exposed and
>> non dereferencable identifier of it's own. Hence my previous mail.
>> 
>> Best,
>> 
>> Nathan
> 
> That would in itself work, but it would violate
> http://tools.ietf.org/html/rfc6415 on which webfinger is based.
> RFC6415 unambiguously states that the specific resources about which
> information is retrieved should be identified by their URIs, not by
> any custom strings. It says additional protocol-specific parameters
> may be used, but identifying the resource should be done with a URI.
> Especially in the two-step setup (when resolving an LRDD template),
> putting "joe@gmail.com" at the place of "{uri}" would be incorrect.
> That's why the choice was made to put "acct:joe@gmail.com" there
> instead. There is a reason that resources are identified by URIs and
> not by per-protocol strings. Namely that if every protocol uses the
> URI format to refer to resources, then everything becomes more
> combinable.
> 
> As i understand it, if the authors of webfinger have tried to change
> RFC6415 to allow referring to resources with protocol-specific strings
> that are not URIs, that would be going against the architecture of the
> web?

You can do if if you think in terms of relations. Here in Turtle:

@prefix oauth: <http://some.domain.tobedeterined/ont/#> .

<https://gmail.com/.well-known/host-meta?resource=acct:joe@gmail.com> a oauth:Account;
   oauth:accountStr "joe@gmail.com" .

You want oauth:accountStr to be an inverse functional property that uniquely identifies an
account . 

Essentially oauth:accountStr's inverse is a function from a string to a resource. let's call that 
inverse oauth:account. Then in functional notation we have

  oauth:account("joe@gmail.com") = <https://gmail.com/.well-known/host-meta?resource=joe@gmail.com>

auth:account is a function that takes a string and maps it to a uri. It is a partial function on strings - not all strings will have results. Those that do should have an e-mail address like syntax, and from that string it can construct the url that is the lookup. It turns out that in rdf you can express this using datatypes.

 "joe@gmail.com"^^oauth:account

so now we can describe a person using foaf via their oauth account using:

  @prefix foaf: <http://xmlns.com/foaf/0.1/> .

  [] a foaf:Person;
     foaf:account "joe@gmail.com"^^oauth:account . 

Add a WebID [1] and you could have

 <http://plug.google.com/joe#me> a foaf:Person;
      foaf:account "joe@gmail.com"^^oauth:name;
      foaf:openid <http://plus.google.com/joe> .   //or wherever google puts its openid

Just some thoughts....

[1] http://webid.info/spec/ 

> 
> 
> Cheers,
> Michiel

Social Web Architect
http://bblfish.net/
Received on Saturday, 23 June 2012 13:38:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:39:58 UTC