Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 29 May 2013 22:12:47 -0400

Folks,

Sal noted that we have several DISCUSS points to cover.  He referred us to this page:
http://tools.ietf.org/wg/appsawg/trac/report/1

Let's take this first item.  I'll start with #12 here.
 
The idea with Host-Meta and, hence, WebFinger, is that a client that wants to know anything about a given URI, it takes the URI and issues a query as per RFC 6415 or per the WebFinger spec.  The intent was to allow any URI, though if one is looking for information about a user's account, the recommendation is to use the 'acct' URI, since it is intended to represent an account owned by a user, versus other URIs like mailto or http.

There may be multiple versions of the story that led us here, but the problem some were trying to address was the use of http URIs for OpenID.  It was hard for users to use.  Users are accustomed to user@domain form of addresses, but then there was the question of what URI to use for those.  The mailto URI could work, but it was not appropriate if one were querying for a user on Twitter, for example.  That and other reasons led to the creation of the 'acct' URI scheme.  And, so we recommend the use of that URI scheme in Section 4.5 of the draft.  However, a client most certainly could query for information about a user using any type of URI.  For example, this is valid:
$ curl https://packetizer.com/.well-known/webfinger?resource=https%3A%2F%2Fwww.packetizer.com

The expected result is JRD that describes the queried resource.  The most useful resource probably is the 'acct' URI today.  The acct URI would return a JRD that describes the account.

So, what is the semantic gap, exactly?  What text can we add to make this clearer without confining WF to being useful only for 'acct' URIs?

Paul

> -----Original Message-----
> From: appsawg issue tracker [mailto:[email-masked]]
> Sent: Wednesday, May 29, 2013 3:21 AM
> To: [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: [appsawg] #12: Semantic gap for the client side
> 
> #12: Semantic gap for the client side
> 
>  the document should clarify how  the client will be able to determine
> what
>  sort of URI to use is the resource part of the query or
>  what the semantics of any given URI are supposed to be.
> 
>  (This a Discuss, present in the IESG Evaluation Record)
> 
> --
> -------------------------------------+------------------------------------
> -
>  Reporter:                           |      Owner:  draft-ietf-appsawg-
>   [email-masked]      |  [email-masked]
>      Type:  defect                   |     Status:  new
>  Priority:  blocker                  |  Milestone:
> Component:  webfinger                |    Version:
>  Severity:  -                        |   Keywords:
> -------------------------------------+------------------------------------
> -
> 
> Ticket URL: <http://tools.ietf.org/wg/appsawg/trac/ticket/12>
> appsawg <http://tools.ietf.org/appsawg/>

---

From: Mike Jones <[email-masked]>
Date: Thu, 30 May 2013 05:13:09 +0000

It's certainly the case that protocols use WebFinger to look up more than identifiers using e-mail address syntax.  For instance, OpenID Connect uses WebFinger to look up URIs that are URLs.  See http://openid.net/specs/openid-connect-discovery-1_0.html#URLSyntax.  Maybe we could give that example?  We could also give the example of MySpace identifiers, which are URLs.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul E. Jones
Sent: Wednesday, May 29, 2013 7:13 PM
To: [email-masked]; [email-masked]
Cc: 'webfinger'
Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side

Folks,

 

Paul

> From: appsawg issue tracker 
> [mailto:[email-masked]]
> what  sort of URI to use is the resource part of the query or  what 
> the semantics of any given URI are supposed to be.
> 
> -------------------------------------+--------------------------------
> -------------------------------------+----
> -
> -------------------------------------+--------------------------------
> -------------------------------------+----
> -
> 

_______________________________________________
webfinger mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/webfinger

---

From: Melvin Carvalho <[email-masked]>
Date: Thu, 30 May 2013 10:27:24 +0200

On 30 May 2013 04:12, Paul E. Jones <[email-masked]> wrote:

> The idea with Host-Meta and, hence, WebFinger, is that a client that wants
> to know anything about a given URI, it takes the URI and issues a query as
> per RFC 6415 or per the WebFinger spec.  The intent was to allow any URI,
> though if one is looking for information about a user's account, the
> recommendation is to use the 'acct' URI, since it is intended to represent
> an account owned by a user, versus other URIs like mailto or http.
>
> There may be multiple versions of the story that led us here, but the
> problem some were trying to address was the use of http URIs for OpenID.
>  It was hard for users to use.  Users are accustomed to user@domain form
> of addresses, but then there was the question of what URI to use for those.
>  The mailto URI could work, but it was not appropriate if one were querying
> for a user on Twitter, for example.  That and other reasons led to the
> creation of the 'acct' URI scheme.  And, so we recommend the use of that
> URI scheme in Section 4.5 of the draft.  However, a client most certainly
> could query for information about a user using any type of URI.  For
> example, this is valid:
> $ curl
> https://packetizer.com/.well-known/webfinger?resource=https%3A%2F%2Fwww.packetizer.com
>
> The expected result is JRD that describes the queried resource.  The most
> useful resource probably is the 'acct' URI today.  The acct URI would
> return a JRD that describes the account.
>
> So, what is the semantic gap, exactly?  What text can we add to make this
> clearer without confining WF to being useful only for 'acct' URIs?
>

The full text may help here:

[[
There appears to be a big giant semantic gap for the client side of this
protocol. I can find nothing in the document that indicates to the client
how it shall determine what sort of URI to use is the resource part of
the query or what the semantics of any given URI are supposed to be. I
suspect that the semantics are so underspecified that there could not
possibly be interoperable implementations without lots of out-of-band
information.

The first example provides a mapping from an email address (or perhaps a
mailto URI; that's not clear) to an acct URI, but neither the example nor
anything in the rest of the document gives any clue why you would choose
to query an "acct" URI based on the contents of an email message. I think
the assumption is that if there is an email address, there must be some
sort of "account" associated with it, and therefore querying the host on
the RHS of the "@" for that account will get some interesting
information. But I don't see any reason to choose an "acct" scheme over
"mailto" or "smtp" or "email" or "foobar"; as far as I can tell, the
choice is semantics-free.

Reading the above alongside 3.3 makes me all the more suspicious: In 3.3
(also mentioned in 4.5), a "mailto" URI gets you configuration
information for all email configuration parameters. Does an "acct" URI
get you configuration information for email *and* xmpp *and* sip *and*
calendaring *and* all other configuration information (since you are no
longer asking for a particular protocol, but rather the general account
information), or do you only get "information" about the person and not
their account? (I might also insert privacy and security worries here,
but see Stephen's DISCUSS regarding that.) How can the client know what
sort of information it can ask for and how to get it? And for that
matter, how does the server tell what information to pass back? You'd
think there would be a hint about this in 4.3, but "rel" only seems to
provide for the client to request those things that the client already
knows about it. In particular, there appears to be no way to say, "Give
me user provided information, but not config information" or "Give me
config information, but not blog entries".

I find the semantics for "device" in 3.4 all-the-more mysterious. As far
as I can tell, this URI scheme simply means, "Give me all of the
information for the entire host."

Again, the semantics of all of these interactions seem so underspecified
that I don't understand how interoperation is supposed to happen.

This also leaves me with the question about why the resource query part
is a URI at all. It seems to me that the resource you are asking about is
not a URI (or URN) at all; it's simply an identifier for an entity that
the particular host knows about. Given that, why not pass a simple
identifier? (See http://datatracker.ietf.org/doc/draft-ietf-radext-nai/
for example.) If the scheme is not providing any particular semantics
about the response, I see no reason to provide the scheme. If more
semantics (beyond rel) are needed, another parameter indicating the type
of identifier being used seems much more appropriate than using a URI
scheme.
]]

---

From: Melvin Carvalho <[email-masked]>
Date: Thu, 30 May 2013 10:41:33 +0200

> problem some were trying to address was the use of http URIs for OpenID.

The original OpenID (codename yadis) actually used Linked Data (in
particular FOAF) as the discovery method.

> It was hard for users to use.

This is commonly claimed, but I'm unconvinced.  HTTP URIs are delivered in
quite a usable way in Facebook.  Indeed every browser has an address bar.
That doesnt mean that every site visited must be typed in.  Point and
click, as popuarized by google's reverse search engine, or cut and paste
are commonly used by users to get HTTP URIs into the address bar.

> Users are accustomed to user@domain form of addresses, but then there was
> the question of what URI to use for those.

Users are accustomed to real names.  That's how friending works on
facebook.

> for a user on Twitter, for example.

Account vs User vs Name vs Person seems to come up all over the place.
Even in financial accounting its sometimes tricky to distinguish between an
account and a person.  In truth I think it's a grey area.  Trying to get
the perfect scheme for this is going to be tricky, just using mailto I
think would be fine.

> That and other reasons led to the creation of the 'acct' URI scheme.  And,
> so we recommend the use of that URI scheme in Section 4.5 of the draft.
>  However, a client most certainly could query for information about a user
> using any type of URI.  For example, this is valid:
> $ curl

This is problematic because linked data (via HTTP GET) also is an existing
discovery process.  Can WF ensure interoperability with existing discovery
methods?  If the client is going to get one result from WF and another from
HTTP GET, how does it know which to choose?

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 30 May 2013 20:08:23 -0400

Melvin,

Thanks for bringing that text forward.

All,

So, the first part of the issue seems to be one of "what URI do I use and
why?"  The answer really is "whatever URI you have".

The second paragraph goes into one area where I understand why one might be
confused.  In the example, the client queried the acct URI and just
fabricated that by taking the email address (of the form user@domain) and
turning that into an account URI.  That said, I don't know I would call that
a semantic gap.  Humans do this.  If you see user@domain, you assume it's an
email address.  Likewise, Microsoft Word will do the same.  For WF, there is
the suggestion that it's safe to assume it can be converted to
acct:user@domain.  That might be a faulty assumption, but so might assuming
that user@domain is an email address if there is no URI scheme.  Even if
there were, the intent of the acct URI is to represent user accounts and the
expectation is that the form would "look like" email addresses.  So, what
can we add to the document to make this clearer?

The third paragraph goes into use of different URI schemes and the expected
results returned.  WebFinger should not prescribing exactly what gets
returned for any particular URI.  The intent of the WF spec is to define the
tool used to perform a query and the syntax of the query and response.
However, how one actually get configuration information or what information
should be returned for a given URI should be defined elsewhere, IMO.  We
expect that account-related information about a user will be returned if one
queries with an acct URI.  We do not want to define what is returned for
mailto: or xmpp: or other.  We might use it for configuration or we may
never use those with WebFinger.  I would say that should be the scope of
another spec.

The example in 3.4 is intended to be mysterious.  It has been a struggle to
provide examples, as some do not like abstract examples and some do not like
concrete examples.  This is one of the more abstract examples; the device
URI scheme does not even exist. The intent of the example is just to show
that WF can be used for a range of things, but the syntax is consistent.
Why a particular URI scheme is used and exactly what links, properties, etc.
will be returned should be defined elsewhere.

The last paragraph asks why the resource part is a URI at all.  That was
debated at length a few years ago when the acct URI scheme was discussed.
Blaine Cook was one in favor of using no scheme at all.  However, there was
a desire to be able to issue a WF query for different URIs, because
different URIs might return different responses.  I appreciate the immediate
question is "what would be different", but I don't think it's the WF spec
that should dictate what gets returned for any particular URI.  The OpenID
specs Mike referenced is a good example that prescribes what to expect using
a given URI scheme.  The OpenID Connect spec can utilize either the acct URI
or an http URI.

What words can we introduce that will help to resolve this issue?

Paul

From: Melvin Carvalho [mailto:[email-masked]] 
Sent: Thursday, May 30, 2013 4:27 AM
To: Paul E. Jones
Cc: [email-masked]; salvatore loreto; webfinger
Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side

Folks,

Sal noted that we have several DISCUSS points to cover.  He referred us to
this page:
http://tools.ietf.org/wg/appsawg/trac/report/1

There may be multiple versions of the story that led us here, but the
problem some were trying to address was the use of http URIs for OpenID.  It
was hard for users to use.  Users are accustomed to user@domain form of
addresses, but then there was the question of what URI to use for those.
The mailto URI could work, but it was not appropriate if one were querying
for a user on Twitter, for example.  That and other reasons led to the
creation of the 'acct' URI scheme.  And, so we recommend the use of that URI
scheme in Section 4.5 of the draft.  However, a client most certainly could
query for information about a user using any type of URI.  For example, this
is valid:
$ curl
https://packetizer.com/.well-known/webfinger?resource=https%3A%2F%2Fwww.pack
etizer.com

The expected result is JRD that describes the queried resource.  The most
useful resource probably is the 'acct' URI today.  The acct URI would return
a JRD that describes the account.

[[

Paul

> From: appsawg issue tracker [mailto:[email-masked]
<mailto:[email-masked]> ]