WebFinger
draft-ietf-appsawg-webfinger-18

I have no objection to the publication of this document, but I have
some questions/concerns. Apologies if these are stupid questions
caused by lack of clue - and in that case please just respond with
"this would be obvious if you had any idea what you were talking
about."

---

Can the WebFinger source provide that his information can be accessed
at different levels by different people. For example, make his blog
and website available to everyone, but his phone number require a
specific access level?

---

I don't understand how the source can certify that the information
being read from the server is information he supplied rather than 
information that a malign (or error-prone) third party has placed 
on their own WebFinger server. Can the information be signed as a
set such that information outside the set is marked as not 
authenticated?

As I understand it, the value of the information supplied by the
WebFinger server depends on the level of trust that the reader places
on the server. Obviously, if my email is hosted by example.com, then
I might trust that the information I write (perhaps through a web
interface) to the example.com server will be present in the WebFinger
response, but what if example.com decides to add to the information or
place data there that I do not want made public? Is the claim that this
is simply an issue for the commercial relationship between me and 
example.com? How does the reader distinguish between information I have
supplied and information example.com has decided to add?

Furthermore, it isn't clear to me what control there is on example.org
supplying WebFinger responses for an example.com user. That is, if the
request is:
  GET /.well-known/webfinger?
                           resource=acct%3Abob%40example.com HTTP/1.1
  Host: example.org

---

I was a bit uneasy about calling the process in the example in Section
3.3 "autoconfiguration". I think, in fact, it is just normal 
configuration. But, of course, it is remote configuration. Perhaps its
would better be called "Configuration Retrieval".

---

I am really uneasy about the inclusion of the example in section 3.4.
Not only is it "totally fictitious", but I think it is widening the
scope of WebFinger into dynamic device-level information. That sort of
thing needs, IMHO, a wider discussion within the IETF.

Since the example is not a real one and is dependent on extensions to
a spec that might not be extended and is out of scope for the IETF,
perhaps we can regard the section as "marketing" in support of
WebFinger. Since WebFinger has clearly been accepted as an idea, would
it be possible to delete this section?

There would also be a small change to the Introduction as well.

I support both Pete's and Stephen's DISCUSS points.

I support Stephen Farrell's questions on privacy, however.

converting to no objection, awaiting the resolution of stephen's discuss which will in all likelihood satisfy me.

Just a comment:

I would add an informative reference to RFC 1288, just for historical completeness. Not everybody still knows finger.

Thank you for addressing my DISCUSSion points exceedingly well. I hope some implementer input will be solicited to firm section 8 up, but it was exactly what I thought was needed. Some additional comments to consider, none of them earth-shattering:

Section 1, last paragraph, suggest adding: "Section 8 describes how applications of WebFinger may be defined."

Section 3, opening paragraph, suggest changing to:

   This section shows a few sample uses of WebFinger. Any application of
   WebFinger would be specified outside of this document, as described
   in section 8. The examples in this section should be simple enough to
   understand without having seen the formal specifications of the
   applications.

Section 3.2, first paragraph: The use of "application" here sounds like "client application", where elsewhere in the document, "application" refers to the "application of use" defined a la section 8. I suggest changing the first paragraph to:

   Suppose an application is defined to retrieve metadata information
   about a web page URL, such as author and copyright information. To
   retrieve that information, a client can utilize WebFinger to issue a
   query for the specific URL.  Suppose the URL of interest is
   http://blog.example.com/article/id/314.  The client would issue a
   query similar to the following:

Section 4:

   ...the host to which the WebFinger query is issued MUST be the same
   as the "host" portion of the query target, unless the client receives
   instructions through some out-of-band mechanism to send the query to
   another host.
   
The "MUST...unless" construction is weird. SHOULD seems better anyway (keeping the explanation, and perhaps adding something about URIs that have no "host" portion).

Section 8.4: Silly grammar-police thing: s/are each comprised of/each comprise/

Section 8.5:

   Any syntactically valid properties or links the client receives and
   that are not fully understood SHOULD be ignored and MUST NOT cause
   the client to report an error.

I think the MUST NOT should be SHOULD NOT. There are cases I can imagine where I define an application where I know I've got to be talking to a server that really understands the question I'm asking, and if I get bogus properties or links that I don't understand, I want to signal to the user that the server in question isn't playing the right game (i.e., isn't properly implementing the application). I think as a general rule, you SHOULD always ignore unknown stuff and SHOULD NOT generate an error, but I can imagine cases where it would be reasonable.

Wow so many discusses.  I've got nothing new to add.

Thanks for handling my discuss points. (By deleting all
the contentious examples you seem to have robbed us 
of the chance for an extended debate, but I guess 
that gives me more time to enjoy the summer weather:-)

One thing you should fix - there's still text in 8.3 referring 
to the old 3.1 that probably should be changed. I'd
suggest:

OLD:

   As an
   example, suppose a mail client was configured to automatically
   perform a WebFinger query as discussed in the example in Section 3.1.

NEW:

   As an
   example, suppose a mail client was configured to automatically
   perform a WebFinger query on the sender of each recieved
   mail message.



--- older comments - didn't check if they've resulted in
changes, and I'm happy to discuss 'em if you want.

Was discuss point (5). Since nobody else is arguing for
this I've made it a comment.

- 8.2 and 8.3, given the privacy and abuse considerations
here why is there no definition for the DELETE method in
order to provide a way for users to be able to at least ask
that their information no longer be available? Or another
.well-known URI could be used. Was that discussed?


---

- Thank you for requiring TLS! That's a good precedent. 

- intro: "facilitate logging into a web site" hmm, lots of
security alarm-bells ring there, maybe better to say
"facilitate, with additional security mechanisms, logging
into a web site" or choose a non-security example?

- 3.2, I'd much prefer that the security of this kind of
interaction be explained, if only by reference, e.g. add
something like "the security aspects of this kind of
interaction are discussed in [ref]." If such a [ref] exists
then that ought be easy and useful. If no such [ref] exists
that would be interesting.

- 4.1, I'm a bit confused here. Can I use WF to ask about
"http://tcd.ie/thing?foo=bar&baz=bat" as the query target? I
think this section says that's ok but I'm not sure so maybe
I'm confused. Maybe making that explicit would be good.  I'm
also not sure that its ok to not percent-encode the "?" in
that query target but I guess it must be ok if you've said
nothing about it.

- 4.3, the example "rel"s are http URLs and not https. Are
these intended never to be de-referenced?  If so, maybe say
so and that its therefore ok to not insist on https?  If not,
then I think you do need to say that de-referencing those
URLs can invalidate some of the confidentiality guarantees
provided by requiring TLS for WF.

- 4.4.3, same comment as for 4.3; maybe for 4.4.4.x too

- section 7 uses the term "service URI" - I think that and
"query target" and "subject URI" would be better defined up
front

- 8.1, you don't say if you require certificate status
checking.  It'd be better to say.

- 8.2, this is outstandingly glib: "If one does not wish to
share certain information with the world, do not allow that
information to be freely accessible on the Internet or
discoverable via WebFinger" - most users are never given a
choice as to whether or not much of their information is
freely accessible or not. I think the best that can be done
with that is to delete it.