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

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

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

Essentially oauth:nameStr's inverse is a function from a string to a resource. let's call that 
inverse oauth:name. Then in functional writing

   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:22:17 UTC