[apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11

[Dave Cridland <[e-mail]>]

I have been selected as the Applications Area Directorate reviewer for this
draft (for background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments you
may receive. Please wait for direction from your document shepherd or AD
before posting a new version of the draft.
Document: draft-ietf-appsawg-webfinger-11
Title: Webfinger
Reviewer: Dave Cridland
Review Date: 2013/03/11
IESG Telechat Date: 2013/03/28
Summary: Close to ready for publication as standards track; some comments
which suggest a new version may be required and/or technical discussion
needed.

Minor Comments:

1) There's some suggestions that webfinger could be used for email
autoconfig; I suspect this is at best going to cause confusion especially
when there's a BOF tomorrow on the subject. This feels like text that
doesn't need to be present.

Also, it's a cursed subject anyway; see ACAP. :-)

Major Comments:

1) I note that §4.4.4.1 describes a 'rel' such that it redefines and
repeats RFC 5988's §4; I think this should be deferred explicitly to RFC
5988 in entirety, rather than specifically only for registered link
relation types.

The good news is that this should simplify the text rather a lot:

"""
The value of the "rel" member is a string containing a link relation type
(see RFC 5988 [4]). Both registered and extended relation types are
permitted.
"""

2) The use of webfinger with arbitrary URIs is something I had not
previously realised. This raises some concerns for me, as it's not clear
whether this is either genuinely desirable or whether it introduces
considerations (security and otherwise) beyond those discussed within the
document.

I would in general rather the mechanism were restricted to acct, http,
https, and perhaps mailto.

3) There is no use of SRV here; I would prefer an SRV resolution step for
at least acct and mailto scheme URIs, and possibly http/https as well. My
concern is that a corporate webserver is typically unlikely to be capable
of providing webfinger services (being often externally hosted), and while
this could be solved by handling redirects, or by reverse proxying, SRV
feels like a more stable solution here.

I'd be curious as to whether this has been discussed.

4) It would make §8 more readable if it were split into subsections. I
think the first three paragraphs form a discussion about the transport
security, the middle paragraphs discuss privacy, and the final paragraph
discusses information reliability.

I suspect there is one more case to be concerned about, which is that it
may be possible for an attacker to use webfinger resources to test the
existence of a hypothetical user; that is, one might use webfinger as a
harvesting mechanism.

Dave.