RFC 7033

Note: This ballot was opened for revision 12 and is now closed.

Barry Leiba Yes

(Jari Arkko) No Objection

Comment (2013-04-09 for -12)
No email
send info
I support Stephen Farrell's questions on privacy, however.

(Richard Barnes) (was Discuss) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) (was Discuss, No Objection) No Objection

(Adrian Farrel) No Objection

Comment (2013-04-10 for -12)
No email
send info
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


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 

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)
No email
send info
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


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


   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

- 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)
No email
send info
I support both Pete's and Stephen's DISCUSS points.

(Joel Jaeggli) (was Discuss) No Objection

Comment (2013-04-18 for -13)
No email
send info
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)
No email
send info
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

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)
No email
send info
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)
No email
send info
Wow so many discusses.  I've got nothing new to add.

(Ted Lemon) (was No Objection, Discuss) Abstain

Comment (2013-04-17 for -13)
No email
send info
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 <paulej@packetizer.com> 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.