Subject: [webfinger] Pete Resnick's Discuss on draft-ietf-appsawg-webfinger-12: (with DISCUSS and COMMENT)

From: "Pete Resnick" <[email-masked]>
Date: Wed, 10 Apr 2013 08:13:41 -0700

Pete Resnick has entered the following ballot position for
draft-ietf-appsawg-webfinger-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[All: As I noted earlier to the Webfinger mailing list, I have Cc'ed this
to the Webfinger list along with the document authors, the document
shepherd, and the rest of the IESG.

Also note that I intend to DISCUSS this until Thursday. If I get no
further support from the IESG and/or the WG that this is a serious and
showstopper problem, I will simply ABSTAIN on both this and on the
-acct-uri document (on which I also currently have an open DISCUSS
position). But it looks like Richard and I are in some agreement on
this.]

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.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Stephen's concerns re: privacy.

---

From: Bob Wyman <[email-masked]>
Date: Wed, 10 Apr 2013 11:42:22 -0400

WebFinger provides a mechanism with which one who discovers a URI can
request metadata associated with that URI or what it represents.

URI hosts are not required to support WebFinger nor are they constrained in
the metadata that can be returned if they do support WebFinger. The
metadata returned may or may not be useful to the requester.

It is anticipated that with usage, hosts that support WebFinger will tend
to report relatively consistent and useful metadata. However, it cannot be
determined at this time what metadata will be most commonly reported or
most commonly useful.

bob wyman

On Wed, Apr 10, 2013 at 11:13 AM, Pete Resnick <[email-masked]>wrote:

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

---

From: Pete Resnick <[email-masked]>
Date: Wed, 10 Apr 2013 14:31:03 -0500

Hi Bob,

You'll note that my DISCUSS point was about the *client* behavior. You 
are talking about the *server* behavior, so this doesn't address my 
concerns.

That said, as I explained in my earlier message, please give the 
document authors/shepherd a chance to formulate a response before 
jumping in. I don't want to run off on too many tangents.

Thanks,

pr

On 4/10/13 10:42 AM, Bob Wyman wrote:
> URI hosts are not required to support WebFinger nor are they 
> constrained in the metadata that can be returned if they do support 
> WebFinger. The metadata returned may or may not be useful to the 
> requester.
>
> It is anticipated that with usage, hosts that support WebFinger will 
> tend to report relatively consistent and useful metadata. However, it 
> cannot be determined at this time what metadata will be most commonly 
> reported or most commonly useful.
>
> bob wyman
>
>
>
> On Wed, Apr 10, 2013 at 11:13 AM, Pete Resnick 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Please refer to
>     http://www.ietf.org/iesg/statement/discuss-criteria.html
>     identifier? (See
>     http://datatracker.ietf.org/doc/draft-ietf-radext-nai/
>     [email-masked] <mailto:[email-masked]>

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 10 Apr 2013 23:39:54 -0400

Pete,

> possibly be interoperable implementations without lots of out-of-band

If you are seeking information related to a user account, then the specification recommends the use of the "acct" URI.  Use of other URI types is not fully specified and no recommendations are given.  Syntactically, the server behavior will be the same for any type of URI.  The only gap is knowing what set of link relations type to expect for a given URI scheme.  Do you use "mailto" or "acct"?  We had a lot of debate over that for years and settled on "acct".

So what should one expect if one issued a query like this?

$ curl https://packetizer.com/.well-known/webfinger?resource=http://www.packetizer.com

I would expect it to return information about that URL.  The link relation types returned might be "copyright" or "author" or other.  It would be types that are valid for a web page.

> choice is semantics-free.

Again, this was a 3 year long discussion.  You're right that it could be anything.  We even argued to use no URI at all and just use "user@domain".  However, it finally decided to use "acct".  It identifies an account at a domain.  It does not identify an email address.  Using mailto URI didn't fit Twitter, for example, as there is no email.  The same can be said for other services, including photo sharing services, blogs, and so forth.  If you want to query information about my account on a social networking site, it would not be an email address that would be used.
 
> config information, but not blog entries".

The "rel" parameter is just a filter to reduce the size of the JRD down to only the particular link relation types of interest (e.g., "vcard", "jcard", "blog", "profile").

If you wish to query for information about a person, you query the person's acct URI.  The other examples, such as use of "mailto" or "device" are just examples of what is possible.   As an example of how I would expect to use "mailto", you can see this presentation:
http://www.ietf.org/proceedings/86/slides/slides-86-aggsrv-3.pdf

However, the aggsrv group could say (if they even elected to use WF) that the "mailto" URI shall be used to query for configuration information related to email.  I don't know what they will recommend.  The WF draft shows an example of how one could use an email URI, but it is a non-working example since none of the link relation types are defined.

The WF spec does not go into detail on what a client should expect to receive for any URI scheme, but only recommends use of "acct" to get user account information.  The link relations returned from such a query are in use today and some will be standardized (as that's next on the "to-do" list).

> information for the entire host."

Well, "device" does not exist and that will likely never exist.  The only point with that was to demonstrate how any URI scheme could be used, including one intended for device identification.  And if we had one for device identification, it might return that kind of information.  Again, this is just a non-normative example showing broadly what we can do with WF.
 
> that I don't understand how interoperation is supposed to happen.

Yeah, this definitely was not intended to be defined.  When or if we decided to use WF for this purpose, it would be defined in another spec.  However, I would expect the syntax and procedures for making the request to the server to be the same as querying for an account URI.
 
> of identifier being used seems much more appropriate than using a URI

URI schemes allow for a natural separation.  And, a WF server for a domain could know all kinds of information about itself.  It would know who authored web pages on the domain.  It would know information about account holders on the domain.  There was back and forth, as I noted above, as to whether we needed "acct" or not.  In the end, it was agreed to identify information about users -- stuff users share or that are shared within a company (e.g., employee pictures or contact info).

Years of work on this topic resulted in RFC 6415.  RFC 6415, in fact, is what people had envisaged for "webfinger".  It defined a well-known location called "host-meta" and a different link relation called "LRDD" for querying information about a particular URI.

The challenge with RFC 6415 is that it too so long to move forward that by the time it was done, JSON had become the favored syntax language, people wanted to mandate use of TLS for a variety of security reasons, people did not want two round trips to the server to return the JRD.  So, we set about fixing all of the gripes people had with RFC 6415.  We removed XML entirely, we fully documented JRD, the server does the merging of host-meta and LRDD documents (though not described that way for simplicity's sake), TLS was mandated, and we introduced the "rel" parameter to allow for selecting one or a few types of links to reduce the size of the document.

RFC 6415 uses any type of URI.  This is useful, since the URI scheme does provide separation in namespace and since we do want to allow retrieval of a set of link relations for those URIs -- web pages (http), user accounts (acct), tel URIs (tel), etc.  The only point of confusion, I think, is "what do we do with mailto, sip, h323, telnet, etc.?"  Well, we're not prescribing that.  That would be documented in a document that wants to use those other URIs.  They might be used to configure a device or help route a call or whatever.  We only have examples of possible use, but we do not specify their use.

Paul

---

From: Goix Laurent Walter <[email-masked]>
Date: Thu, 11 Apr 2013 10:30:35 +0200

Dear all,

After reading this thread and the various ballots, I'd like to help the DISCUSSion and hopefully clarify (part of) the doubts by proposing an example of usage of webfinger within federated social networks. This example is derived from the OMA Social Network Web specification, which references Webfinger for this specific purpose.
I'd also like to recall (as Paul anticipated talking about rfc6415) that social network federation was actually the first use case of the original webfinger community spec, and as such imo well deserves an example using this new spec as it may become extremely relevant in the next years.

Of course improvements are welcome if the generic idea is sound.

Walter

---
3.x Federated Social Networks
In the context of interoperable, federated, social networks, the Webfinger discovery process is used by a SN Server when receiving a request from an SN Client on behalf of a user asking to interact with a user identified by his SN account eg acct:[email-masked]. In particular the SN Server identifies whether it is authoritative for the recipient (i.e. the domain of his/her account is "locally" managed by this SN Server) or whether it pertains to another remote SN domain/provider. If the recipient's address corresponds to a "acct:" address, which domain-part corresponds to a remote domain, the SN Server can locate the recipient's SN Server based on this domain-part and trigger the Webfinger discovery process for that recipient (the "resource").
This process can hence be triggered when receiving requests to follow remote users or when receiving reactions (e.g. comments, replies, mentions) that relate to social activities of remote users, etc. Depending on the incoming request from the client, the SN Server may be interested in some specific link rels that will be used to contact the remote SN Server on the related endpoint(s). SN Servers can cache the information provided in the retrieved descriptor and/or issue conditional requests at a later stage to check for updates of this information, subject to the mechanisms defined in [RFC 2616] section 13.

The following JRD is an example of a user descriptor returned by an SN Server for a Webfinger query to user account acct:[email-masked]. In this request no specific rel is mentioned as it may be useful for the requesting SN Server to cache to entire descriptor for future needs.

{
       "subject" : "acct:[email-masked]",
       "properties" :
       {
           "http://salmon-protocol.org/ns/magic-key" : "RSA.mVgY8RN6URBTstndvmUUPb4UZTdwvwmddSKE5z_jvKUEK6yk1u3rrC9yN8k6FilGj9K0eeUPe2hf4Pj-5CmHww.AQAB"
       },
       "links" :
       [
         {
           "rel" : "http://portablecontacts.net/spec/1.0",
           "href" : "http://example.com/api/people"
         },
         {
           "rel" : "http://portablecontacts.net/spec/1.0#me",
           "href" : "http://example.com/api/people/joe"
         },
         {
           "rel" : "http://ns.opensocial.org/2008/opensocial/people",
           "href" : "http://example.com/api/people"
         },
         {
           "rel" : "http://webfinger.net/rel/profile-page",
           "type" : "text/html",
           "href" : "http://example.com/profiles/joe"
         },
         {
           "rel" : "describedby",
           "type" : "text/html",
           "href" : "http://example.com/profiles/joe"
         },
         {
           "rel" : "http://webfinger.net/rel/avatar",
           "href" : "http://example.com/profiles/joe/photo"
         },
         {
           "rel" : "http://schemas.google.com/g/2010#updates-from",
           "type" : "application/atom+xml",
           "href" : "http://example.com/activities/joe"
         },
         {
           "rel" : "salmon",
           "href" : "http://example.com/salmon/joe"
         }
       ]
}

Depending on the original request from the client the SN Server will typically read a specific link rel and invoke the related endpoint. For example it can read the http://schemas.google.com/g/2010#updates-from relation link of type "application/atom+xml" to access the user's activity stream feed or the http://portablecontacts.net/spec/1.0 relation link to access personal user information such as his profile or relationships. The actual access to such endpoints and the retrieved data ,if any, will be subject to the remote SN policies and user settings.

> -----Messaggio originale-----
> Da: [email-masked] [mailto:[email-masked]] Per conto
> di Paul E. Jones
> Inviato: giovedì 11 aprile 2013 5.40
> A: 'Pete Resnick'; 'The IESG'
> Cc: [email-masked]; [email-masked]; draft-ietf-appsawg-
> [email-masked]
> Oggetto: Re: [webfinger] Pete Resnick's Discuss on draft-ietf-appsawg-
> webfinger-12: (with DISCUSS and COMMENT)
>
> Pete,
>
> If you are seeking information related to a user account, then the
> specification recommends the use of the "acct" URI.  Use of other URI types is
> not fully specified and no recommendations are given.  Syntactically, the
> server behavior will be the same for any type of URI.  The only gap is knowing
> what set of link relations type to expect for a given URI scheme.  Do you use
> "mailto" or "acct"?  We had a lot of debate over that for years and settled on
> "acct".
>
> $ curl https://packetizer.com/.well-
> known/webfinger?resource=http://www.packetizer.com
>
> I would expect it to return information about that URL.  The link relation
> types returned might be "copyright" or "author" or other.  It would be types
> that are valid for a web page.
>
> Again, this was a 3 year long discussion.  You're right that it could be
> anything.  We even argued to use no URI at all and just use "user@domain".
> However, it finally decided to use "acct".  It identifies an account at a
> domain.  It does not identify an email address.  Using mailto URI didn't fit
> Twitter, for example, as there is no email.  The same can be said for other
> services, including photo sharing services, blogs, and so forth.  If you want
> to query information about my account on a social networking site, it would
> not be an email address that would be used.
>
> The "rel" parameter is just a filter to reduce the size of the JRD down to
> only the particular link relation types of interest (e.g., "vcard", "jcard",
> "blog", "profile").
>
> If you wish to query for information about a person, you query the person's
> acct URI.  The other examples, such as use of "mailto" or "device" are just
> examples of what is possible.   As an example of how I would expect to use
> "mailto", you can see this presentation:
> However, the aggsrv group could say (if they even elected to use WF) that the
> "mailto" URI shall be used to query for configuration information related to
> email.  I don't know what they will recommend.  The WF draft shows an example
> of how one could use an email URI, but it is a non-working example since none
> of the link relation types are defined.
>
> The WF spec does not go into detail on what a client should expect to receive
> for any URI scheme, but only recommends use of "acct" to get user account
> information.  The link relations returned from such a query are in use today
> and some will be standardized (as that's next on the "to-do" list).
>
> Well, "device" does not exist and that will likely never exist.  The only
> point with that was to demonstrate how any URI scheme could be used, including
> one intended for device identification.  And if we had one for device
> identification, it might return that kind of information.  Again, this is just
> a non-normative example showing broadly what we can do with WF.
>
> Yeah, this definitely was not intended to be defined.  When or if we decided
> to use WF for this purpose, it would be defined in another spec.  However, I
> would expect the syntax and procedures for making the request to the server to
> be the same as querying for an account URI.
>
> URI schemes allow for a natural separation.  And, a WF server for a domain
> could know all kinds of information about itself.  It would know who authored
> web pages on the domain.  It would know information about account holders on
> the domain.  There was back and forth, as I noted above, as to whether we
> needed "acct" or not.  In the end, it was agreed to identify information about
> users -- stuff users share or that are shared within a company (e.g., employee
> pictures or contact info).
>
> Years of work on this topic resulted in RFC 6415.  RFC 6415, in fact, is what
> people had envisaged for "webfinger".  It defined a well-known location called
> "host-meta" and a different link relation called "LRDD" for querying
> information about a particular URI.
>
> The challenge with RFC 6415 is that it too so long to move forward that by the
> time it was done, JSON had become the favored syntax language, people wanted
> to mandate use of TLS for a variety of security reasons, people did not want
> two round trips to the server to return the JRD.  So, we set about fixing all
> of the gripes people had with RFC 6415.  We removed XML entirely, we fully
> documented JRD, the server does the merging of host-meta and LRDD documents
> (though not described that way for simplicity's sake), TLS was mandated, and
> we introduced the "rel" parameter to allow for selecting one or a few types of
> links to reduce the size of the document.
>
> RFC 6415 uses any type of URI.  This is useful, since the URI scheme does
> provide separation in namespace and since we do want to allow retrieval of a
> set of link relations for those URIs -- web pages (http), user accounts
> (acct), tel URIs (tel), etc.  The only point of confusion, I think, is "what
> do we do with mailto, sip, h323, telnet, etc.?"  Well, we're not prescribing
> that.  That would be documented in a document that wants to use those other
> URIs.  They might be used to configure a device or help route a call or
> whatever.  We only have examples of possible use, but we do not specify their
> use.
>
> Paul
>
>

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.