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: Thu, 24 May 2012 11:25:21 +0200
Cc: "www-tag@w3.org List" <www-tag@w3.org>, "Paul E. Jones" <paulej@packetizer.com>, public-philoweb@w3.org, public-webid <public-webid@w3.org>
Message-Id: <DC7C1D5D-C708-4427-98CE-60CD5BFCDF64@bblfish.net>
To: Noah Mendelsohn <nrm@arcanedomain.com>

On 23 May 2012, at 17: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.
> 
> So for example you can do this
> 
> <http://bblfish.net/#hjs> a foaf:Person;
>       foaf:openid <http://bblfish.net/>;
>       foaf:mbox <mailto:henry.story@bblfish.net>;
>       foaf:account <accnt:henry.story@gmail.com> .
> 
> Since foaf:openid, foaf:mbox and foaf:account are inverse functional that is they
> indirectly all identity the same individual identified by <http://bblfish.net/#hjs>
> (namely the person writing this e-mail), then you can see that all of these are in
> some ways identifying.
> 
> Those all identify me in some way, though in the case above only
> <http://bblfish.net/#hjs> refers to me directly.
> 
> the openid refers to my openid page (which is the same as my home page)
> the mbox refers to one of my mailboxes
> the account refers to an online account at google.

Thinking about it further the above shows that one has to be careful with
the way people in the identity space speak of Identifiers. I think there is 
an amalgamation there of direct and indirect identification. 

Indeed one often get talk such as: "if you have enough background information, any
 graph of relation about an individual can be identifying. The age and the zip
code of someone can identify that person, if you have a database of the ages of 
every citizen and their zip code". 

Direct Identification,
is what URIs do: from a logical point of view they REFER . The reference relation
is a relation, as foaf:mbox is too, but it is between a string (the uri) and the thing. 
One could write in n3

"http://xmlns.com/foaf/0.1/mbox"^^xsd:anyUri log:refers <http://xmlns.com/foaf/0.1/mbox> .

foaf:mbox (the thing not the string) is a relation between an object (the mailbox) and 
the person - as expressed using sentences that use strings to refer to things in the world.

Of course if one wanted to be fully formal one would have to describe the things that 
are syntactic with reference to a language (grammar: syntax + semantics) and an interpretation 
procedure. Many things can  be strings, and these can have different interpretations depending 
on the language used. But once that choice has been made, the reference relation from strings
or tokens is fixed by the semantics of the language.

The WebID protocol ( http://webid.info/spec/ ) is using the Identifier aspect of a URI in the
REFERENCE relation sense (log:reference) to identify an agent.  A WebID refers to a foaf:Agent.
But the method of verification that the correct foaf:Agent is referred to uses the indirect
relation between the foaf:Agent and the knowledge of a private key.

 <http://bblfish.net/#hjs> cert:key :pubKey1 .

cert:key is an inverse functional relation. The TLS protocol verifies knowledge of the private 
key corresponding to the public key in the X509 certificate, and uses this as an indirect identifier 
for the  WebID . Of course other ways of proving that knowledge could work. And indeed other 
proof procedures can work. So protocols like WebID don't determine one unique authentication mechanism.
One can combine it with others such as OpenID: proving that one has an OpenID can also be used to identify
an agent.

> <http://bblfish.net/#hjs> a foaf:Person;
>       foaf:openid <http://bblfish.net/>;
>       foaf:mbox <mailto:henry.story@bblfish.net>;
>       foaf:account <accnt:henry.story@gmail.com> .

similarly proving (via having an email sent) that one is in control of an mbox, 
can also be used to identify the agent (via the foaf:mbox relation ), in this
more general sense of identify.

To tell the truth one does not even need a WebID in that case. One can
use a blank node (an existential quantifier) to identify a person, using
any number of (inverse functional relation + Identifier pairs)

[] a foaf:Person;
   foaf:openid <http://bblfish.net/>;
   foaf:mbox <mailto:henry.story@bblfish.net>;
   foaf:account <accnt:henry.story@gmail.com>;
   cert:key :pubkey1 .

  
So I think perhaps the WebID group, having now got the WebID+TLS part sorted,
could write this up. From there one can go an to show how one can tie together
any number of what are known as identification protocols together.


  
>> 
>> I don't feel sufficiently informed on the details to respond formally on apps-discuss, but I strongly suspect that an architecturally preferable solution would be to use an http scheme URI, and introducing new media types as necessary, with appropriate http status codes, redirections, etc., to indicate that the data returned is about an individual.

I hope that helps. Perhaps you can point them to this discussion and to the WebID community group.

>> 
>> Noah
>> 
>> -------- Original Message --------
>> Subject: 	Re: [apps-discuss] The acct: scheme question
>> Date: 	Tue, 22 May 2012 09:57:15 -0400
>> From: 	Paul E. Jones <paulej@packetizer.com>
>> To: 	'Murray S. Kucherawy' <msk@cloudmark.com>, <apps-discuss@ietf.org>
>> 
>> 
>> 
>> Murray, et al,
>> 
>> I invite others to weigh in on this discussion, but I do want to restate my
>> thoughts on this issue.
>> 
>> The WebFinger draft introduces only minor enhancements over the current RFC
>> 6415. Specifically, it:
>> 
>> ·Mandates server support for JSON
>> 
>> ·Introduces the “resource” parameter
>> 
>> ·Introduces the “rel” parameter
>> 
>> ·Requires support for CORS (at least in most situations; this has been
>> softened a bit to consider enterprise security requirements in the -05 draft)
>> 
>> ·Introduces the “acct” URI scheme for identifying individuals
>> 
>> ·Introduces the “acct” link relation to refer to user accounts
>> 
>> I believe the group is largely in agreement on everything, except the
>> introduction of the “acct” URI. There was some debate over server-side
>> requirement for both XML and JSON, need for “rel”, etc. I view all of these
>> as binary decisions and the group could easily cast a vote.
>> 
>> The question of whether to include the “acct” URI or not I believe largely
>> depends on whether this URI scheme would have utility outside of WebFinger.
>> If it does have other uses then it might make sense to have it stand on its
>> own. At present, the only use I can see for it is for discovery of
>> information about people via WebFinger.
>> 
>> Further on that point, the “acct” URI scheme was, in fact, one of the more
>> significant reasons we introduced this new Internet Draft. After all, RFC
>> 6415 defines the framework for discovery. The “acct” URI scheme, which was
>> heavily discussed previously among interested parties, was not a part of
>> that RFC. Even so, it was implemented and cited in various documents,
>> blogs, etc. Thus, we wanted to formalize it and also introduce addition
>> minor restrictions and enhancements that make WebFinger more useful for
>> discovering information about people. Those additions are enumerated above
>> (e.g., the “resource” parameter, requirement for JSON, etc.).
>> 
>> The debate over the “acct” URI scheme still seems to be centered on the
>> argument that we either do not need a URI scheme at all or we can re-use an
>> existing scheme. I am very much opposed to a scheme-less solution, since
>> RFC 6415, link relations, and Web-Linking, HTML, and all related work upon
>> which WebFinger depends relies on URIs. The URI is what is used to
>> differentiate one type of entity from another. A query for “mailto:”, for
>> example, might return information about one’s mail servers, mail accounts
>> (e.g., POP or IMAP configuration information), etc. A query for “xmpp:”
>> might return information about one’s XMPP server, buddy list, etc. A query
>> for “sip:” might return information about a user’s SIP registrar, outbound
>> SIP proxy, or other configuration information.
>> 
>> Of course, one could build a WebFinger server to return everything about a
>> user regardless of the URI scheme. I just think that is an inappropriate
>> way to respond to a WebFinger query. The “acct” URI was intended to be the
>> single URI scheme that would return information /about/ a person (or
>> possibly a thing) that holds an account at a given domain. It would be the
>> one URI scheme that would return information like vcards, OpenID
>> identifiers, references to social networking pages, photo sharing
>> resources, etc. It might also return other URIs like
>> “sip:paulej@packetizer.com” or “mailto:paulej@packetizer.com”, which is
>> information /about/ me and ways to contact me.
>> 
>> There are perhaps many agreements to be reached through accepted practice,
>> further extensions to WebFinger (and I would love one that defines how to
>> have my email client auto-provision itself), etc. However, I view the
>> “acct” URI scheme and link relation as integral to WebFinger. Without it,
>> discovery would have to be performed using some other less neutral URI
>> scheme that isn’t quite right. Another scheme would work, but it would not
>> be the cleanest approach, IMO.
>> 
>> Normally, I like taking a pragmatic approach to solving problems and will
>> not argue for architectural purity. However, we have an opportunity to make
>> the right selection right out of the gate with WebFinger. It would be
>> trivial for us to implement /any/ choice at this point. We could build
>> everything around “mailto:”, but not all service providers offer email
>> accounts (e.g., Twitter) and it’s entirely nonsensical for other accounts
>> (e.g., PhotoBucket). As such, I’d like to argue for using “acct” to refer
>> to information related to an individual’s account at a domain and to retain
>> that URI scheme within the WebFinger document.
>> 
>> Paul
>> 
>> *From:*apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
>> *On Behalf Of *Murray S. Kucherawy
>> *Sent:* Tuesday, May 22, 2012 3:23 AM
>> *To:* apps-discuss@ietf.org
>> *Subject:* [apps-discuss] The acct: scheme question
>> 
>> As we prepare to bring webfinger into appsawg, it looks a lot like there’s
>> substantial discussion just on the point of the proposed “acct:” scheme.
>> 
>> So, a question for those tracking the discussion: Is this a big enough
>> topic that it should be split into its own document? This would be a useful
>> thing to decide as we figure out how to handle the work once it enters
>> working group mode.
>> 
>> (This by itself has me wondering if we should revisit the conversation
>> about whether webfinger needs its own working group, but I’ll leave it to
>> Barry and Pete to make that call.)
>> 
>> -MSK
>> 
>> <Attached Message Part.txt>
> 
> Social Web Architect
> http://bblfish.net/
> 

Social Web Architect
http://bblfish.net/
Received on Thursday, 24 May 2012 09:26:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 24 May 2012 09:26:07 GMT