Note: This ballot was opened for revision 12 and is now closed.Search Mailarchive
(Barry Leiba) Yes
(Jari Arkko) No Objection
Comment (2013-04-09 for -12)
I support Stephen Farrell's questions on privacy, however.
(Richard Barnes) (was Discuss) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
Benoit Claise (was Discuss, No Objection) No Objection
(Adrian Farrel) No Objection
Comment (2013-04-10 for -12)
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.
(Stephen Farrell) (was Discuss) No Objection
Comment (2013-07-10 for -15)
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.
(Brian Haberman) No Objection
Comment (2013-04-10 for -12)
I support both Pete's and Stephen's DISCUSS points.
(Joel Jaeggli) (was Discuss) No Objection
Comment (2013-04-18 for -13)
converting to no objection, awaiting the resolution of stephen's discuss which will in all likelihood satisfy me.
(Pete Resnick) (was Discuss) No Objection
Comment (2013-08-21 for -17)
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.
(Martin Stiemerling) No Objection
Comment (2013-04-07 for -12)
Just a comment: I would add an informative reference to RFC 1288, just for historical completeness. Not everybody still knows finger.
(Sean Turner) No Objection
Comment (2013-04-11 for -12)
Wow so many discusses. I've got nothing new to add.
(Ted Lemon) (was No Objection, Discuss) Abstain
Comment (2013-04-17 for -13)
Pete has rightly pointed out that my comments below are more consistent with "Abstain" than "No Objection." In addition to the concern I've expressed below, I also agree with Pete's concern that the specification as to how to issue a query is too vague to promote interoperability. The more I try to come up with a helpful suggestion for how to make this document do what I think it should with respect to authentication and authorization, the more I feel like I've waded into quicksand. I think that what I originally asked in my DISCUSS is actually impossible, so I've cleared the DISCUSS, not because I feel it's been addressed, but because it's probably unreasonable to ask the authors to address it. For what it's worth, here's the most recent reply I crafted to Paul Jones on the topic. I don't think what I said in here is exactly right, so I don't propose that the authors do what I ask below, but I also don't think it's completely unreasonable: On Apr 11, 2013, at 9:46 PM, Paul E. Jones <firstname.lastname@example.org> wrote: > For WebFinger, though, the access control mechanism is HTTP-based > authentication. It will either be: > - No authorization required (likely the norm for most queries to > /.well-known/webfinger) > - Basic authentication (OK since all requests are over HTTPS) > - OAuth tokens or similar (not fully explored, but potentially useful > for allowing trusted third parties to access one of your WF- > referenced resources) What I would like to see somewhere in this is first of all that the document explicitly says something like what you just said above—I don't think it does at the moment. Secondly, that it goes into a little more detail about this. I'm thinking about no more than an additional page of text, and preferably less, not a dozen pages. The detail would include implications of "no authorization." It would talk very generally about per-URI access control on the basis of authentication tokens appearing on access control lists. It would talk very generally about mapping provided authentication information, whether it's none, basic, or OAuth, to roles that appear on access control lists. And it would talk, again very generally, about how to return more or less complete results on the basis of those roles. You already have text in the document that alludes to this. I'm not asking for something that's hugely more detailed than what's in the document now; it's just that what's in the document now only implies any of this to someone who has already drunk the authentication/authorization kool-aid. As for why I think you ought to do this when http doesn't do it, it's because this is very clearly a protocol about sharing user-specific information, and the information you're talking about very clearly includes information the privacy of which many users would want to control to varying degrees. A simple binary private/authenticated flag is too coarse, and will lead to people being forced to make unsafe privacy choices. I don't think you have to define a new authentication protocol, or that you should flesh out a complete authorization and access control system. But I am deeply uncomfortable with the idea of saying nothing about this issue here.