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

"Paul E. Jones" <> Sat, 23 March 2013 19:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0CB521F8D7A; Sat, 23 Mar 2013 12:04:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.481
X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HpgLZfvoyYDj; Sat, 23 Mar 2013 12:04:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 906B421F8D32; Sat, 23 Mar 2013 12:04:47 -0700 (PDT)
Received: from sydney ( []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id r2NJ4jAO010965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 Mar 2013 15:04:45 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=dublin; t=1364065486; bh=mPYXxI4vF8qEzw0JOTB3ohLPa7BUQe2Q8XhxByoN1FY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=qmBDzbnUS2OnGo4MzvzZPlwnU6QvkNNgTitPfnckiFGgYJx92tnhYnGcCApcvvQ+5 vPZgUgMHbvVHNviOYGAijWhfH79Nu+AxNdOoeOcBTDFjM3UJwMUvfdl3jb9yhE0r/L K+B228H+VUYgGU+2rW/r8m00j3RRqoNMr6CjL6Z4=
From: "Paul E. Jones" <>
To: 'Dave Cridland' <>
References: <> <053c01ce25cc$8cca5730$a65f0590$> <> <012301ce26a8$0d940a10$28bc1e30$> <> <> <>
In-Reply-To: <>
Date: Sat, 23 Mar 2013 15:05:08 -0400
Message-ID: <03b401ce27f9$5668c5d0$033a5170$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_03B5_01CE27D7.CF57E920"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI6xtTU7bBnElLUOVycpt5dUnTbtQEse7f/Af/Bk0cCFB98AAKS9xmXAYAzFy4B85JRI5eAJN1Q
Content-Language: en-us
Subject: Re: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 23 Mar 2013 19:04:50 -0000



An "http" URI could be used to query information about a web page.  It might
return "copyright" or "author" or other defined link relation values.  Had
WF existed when OpenID 2.0 was drafted, it could have been used to resolve
the OpenID Provider information for a given OpenID identifier.  WebFinger
might be used to find other information about things on the Internet,
including printer, refrigerators, thermostats, or whatever.  What one would
or should expect for various URI schemes is not fully-defined, except that
any URI will return a JRD document with links.  How those links are
interpreted will be defined by whatever document defines the link relation
types or some document such as "Discovering Information about X using
WebFinger" (where "X" might be a printer, thermostat, or whatever).


So, it's not accurate to say the document is scoped to return information
only about individuals.  We put most of the emphasis there, because that has
the most immediate practical use and we expect the 'acct' URI type to be
used primarily.





What should we add?  I'm not seeing any new or different security issues
arising from use of any particular URI scheme.  Every URI returns either a
JRD or it does not.  What would be different with mailto, http, sip, tel,
gopher, or any other scheme?


sip, simple mailto, acct, xmpp, and so on - those URIs which refer
explicitly to an individual - are, I think, adequately considered in the


http seems to be considered only when referring to a person. However, in
general http resources can have links anyway, so I'm not concerned about
these - however I'm not sure that the fragment identifier needs to be sent.


I'm entirely willing to believe you've considered these considerably more
than that, however there's no evidence of it in the specification as


I've spent very little time considering what might happen (beyond a 404)
with arbitrary URI schemes. Should a client ever send a file: URI, for
example? I'm not concerned with what information in the JRD it might be
expecting, or whether or not the WF server understands it, but what
information transfer has occurred and whether this is safe and can
reasonably be expected to be interoperable.


For example, I'd expect a sensible WF client to only ever send a simple
mailto:local-part@domain URI to a server, and if the initial input was one
of the deliciously complex forms, to strip away the header fields and body
and extract (if needed) the To field value. I have no clue what a WF server
might usefully do with a subject line, mind, whether it's malicious or not -
I just think it doesn't need to have it.


I'd suggest simply stating that the security considerations and protocol are
scoped to consider only URIs identifying an individual entity, (perhaps give
some simple examples), and that use beyond that may involve further security
considerations. Then everyone's happy.