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

["Paul E. Jones" <[e-mail]>]

Dave,

 

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.

 

Paul

 

 

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
specification.

 

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
written.

 

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.

 

Dave.