WebFinger
draft-ietf-appsawg-webfinger-18

[Ballot comment]
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.

[Ballot comment]

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.

[Ballot comment]
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  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.

[Ballot comment]
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 to 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  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.

[Ballot discuss]
There appears to be a big giant semantic gap for the client side of this protocol. I can find nothing in the document that indicates to the client how it shall determine what sort of URI to use is the resource part of the query or what the semantics of any given URI are supposed to be. Indeed, the -13 version of the document adds a paragraph more or less saying that this is intentional:

  The WebFinger protocol is designed to be used across many
  applications.  Applications that wish to utilize WebFinger will need
  to specify properties, titles, and link relation types that are
  appropriate for the application.  Further, applications will need to
  define the appropriate URI scheme to utilize for the query target.

I suspect that the semantics are so underspecified that there could not possibly be interoperable implementations without lots of out-of-band information.

1. The first example provides a mapping from an email address (or perhaps a mailto URI; that's not clear) to an acct URI, but neither the example nor anything in the rest of the document gives any clue why you would choose to query an "acct" URI based on the contents of an email message. I think the assumption is that if there is an email address, there must be some sort of "account" associated with it, and therefore querying the host on the RHS of the "@" for that account will get some interesting information. But I don't see any reason to choose an "acct" scheme over "mailto" or "smtp" or "email" or "foobar"; as far as I can tell, the choice is semantics-free.

Reading the above alongside 3.3 makes me all the more suspicious: In 3.3 (also mentioned in 4.5), a "mailto" URI gets you configuration information for all email configuration parameters. Does an "acct" URI get you configuration information for email *and* xmpp *and* sip *and* calendaring *and* all other configuration information (since you are no longer asking for a particular protocol, but rather the general account information), or do you only get "information" about the person and not their account? How can the client know what sort of information it can ask for and how to get it? And for that matter, how does the server tell what information to pass back? You'd think there would be a hint about this in 4.3, but "rel" only seems to provide for the client to request those things that the client already knows about it. In particular, there appears to be no way to say, "Give me user provided information, but not config information" or "Give me config information, but not blog entries". If the intention of the document is to ignore this issue and leave it to other documents or just the implementation to define (as implied by the new paragraph in the intro), I'd say that this protocol is not complete and therefore not interoperable.

2. I disagree with Benoit about the need for Webfinger to return only static info and therefore object to the addition of the text to the intro regarding static vs. dynamic:

  The information is intended to be static in nature and, as such,
  WebFinger is not intended to be used to return dynamic information
  like the temperature of a CPU or the current toner level in a laser
  printer.

Benoit's objection is certainly a design preference, but is not appropriate as a DISCUSS and certainly is not an appropriate change to make without WG consensus, which was not obtained. I think it is perfectly reasonable for Webfinger to return dynamic information (indeed, it certainly will in the case of human account information), and this restriction is inappropriate just to satisfy a particular AD's preferences.

[Ballot comment]
1. After discussions, I now understand why a URI might be useful as the resource target of a query. (E.g., I might want to see if there is information about a particular web page that will lead me to its author, etc.) However, I am still a bit confused about why a URI is the *only* thing I can query. The new text on the importance of the host info increases this confusion:

  The host to which a WebFinger query is issued is significant.  If the
  query target contains a "host" portion (Section 3.2.2 of RFC 3986),
  then the host to which the WebFinger query is issued MUST be the same
  as the "host" portion of the query target. If the query target does
  not contain a "host" portion, then the client MAY choose a host to
  which it directs the query based on local policy.

If the URI need not have a host portion and you can therefore target any host, I don't see why the resource portion of the query needs to be a URI. As I said earlier, it seems reasonable to pass any sort of identifier. (See http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ for example.) If more semantics (beyond rel) are needed, another parameter indicating the type of identifier being used seems much more appropriate than using a URI scheme.

2. I see no justification for the restriction in the above for querying only the host that is in the host portion of a URI. Please explain.

3. I agree with Stephen's concerns re: privacy.

[Ballot discuss]

This is just a quick update to clear the discuss points
that are obviously already handled in -13. Some
points are not yet ready to clear, but I need to update
the discuss text as -13 does partially address point
(1) in particular.

I'll get that done later, hopefully today/tomorrow.

I've not touched the comments below so far except
to make what was discuss point (5) a comment.

----

As will be seen, I (still) have issues with the privacy
aspects of this specification. Some of those are most
apparent through the use-cases/examples so I've taken the
unusal step of DISCUSSing those since they really seem to
convey the real intent of this protocol. To an extent, some
of the suggested changes there do represent personal
preferences of mine but I believe that the DISCUSSion is
still worth having between the authors and IESG and perhaps
the WG.

(1) 3.1, having the MUA automatically do the webfinger thing
is a privacy disaster and would cause MUAs to visit sources
of spam continually and to expose the email addresses of
their correspondents. Other references to having a UA
automatically do webfinger also need to be deleted kind of
behaviour needs to be the subject of a "MUST NOT" statement
IMO. In fact, it already is, since 8.2 says: "WebFinger MUST
NOT be used to provide any personal data to any party unless
explicitly authorized by the person whose information is
being shared." Having a MUA automatically send out a WF
request where the query target is the mail sender/from
contradicts this requirement. The 3.1 example also fits the
anti-pattern given in 8.3. Suggested fix, easy: say that a
MUA MUST NOT do the automatic thing, as per 8.2, which would
be a fine forward reference.

(2) 3.3, this example is odd - why should Sue expose her
username in this interaction - there's no occurrence of
anything clearly user-dependent in the response except what
was given in the request. Why should we expose user
information unnecessarily in this manner? I think the fix
here is for user Sue to send a request for "anon@example.com"
and for the text to specifically say that making use of the
real username isn't a good plan and making use of an invented
non-existent string for username in this case is a fine plan
and perhaps even specifying such a "nonexistent" username
value that can be supported by and understood by all clients
and servers and saying when it'd be sensible to use that.

(3) 3.4, making devices discoverable like this, esp if device
type and firmware revisions were to be exposed represents a
significant increase in an existing risk.  (We had a recent
discussion related to vCard for a similar use case.) This
section seems to be too speculative to be honest, so I'd
suggest just deleting it. If not, maybe add text like that
added in the vCard case.

(4) cleared

(5) made this a comment

(6) cleared

[Ballot comment]

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.

[Ballot comment]
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  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.

[Ballot comment]
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  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.

[Ballot comment]
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  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.

[Ballot discuss]
1. In general, this seems like more of a "framework" document than an actual protocol.  It concerns me to put something like that on the Standards Track without some plan to add more specificity.  As the document stands, it defines a generic system for mapping an octet string to a set of attribute/value pairs.  While that level of generality can be useful for building applications, it makes it hard to evaluate the security and privacy implications.  I think this is what's at the root of Stephen's DISCUSS points on the examples.  If this were part of a working group that were chartered to define details, this would be fine as a first deliverable.  But it doesn't really seem to stand on its own.

Setting those concerns aside for the moment, I have some concerns about the interoperability of this protocol.  While the JSON body returned from a query is well specified, the process of making a query is much less so.

2. Section 4.1. does not actually tell the implementor how to construct a WebFinger URI.  A few issues/questions that need to be addressed:

2.1. What are the inputs to this process?  An "acct:" URI and optional "rel" values?

2.2. How does one choose the host part of the WebFinger URI?

2.3. The section as it currently stands allows arbitrary octet strings to be placed in the "resource" and "rel" fields.  Is that
really your intention?  It seems like these should be constrained to something like the syntax of the "source" and "rel" fields in the JRD, namely, an ASCII token or URI.

2.4. The scheme and path paragraphs from 4.2. should be moved up to this section.

3. Section 4.2. I couldn't figure out what HTTP methods a client is allowed to use.  It seems to me that it would be sensible to allow only GET, unless there is a concrete use case for something else. 

4. Section 4.5. says "use of the "acct" URI scheme is recommended, since it explicitly identifies an account accessible via WebFinger".  This does not seem compatible with what is in draft-ietf-appsawg-acct-uri, "Therefore, any protocol that uses 'acct' URIs, such as the WebFinger protocol [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol [I-D.jones-simple-web-discovery],"  Suggest removing this text.

5. In general, the use of "acct" URIs do not seem all that useful.  The only way they are used in the example use cases are (1) as a replacement for a "mailto" URI, and (2) as a "dummy" URI scheme for a "user@host" string lacking other context.  In the former case, you might as well have just used the "mailto" URI.  The latter case is kind of artificial, since the whole example is premised on the use of "acct".  It might help motivate these URIs if Section 4.1. actually used part of the resource URI to derive part of the WebFinger URI, e.g., using the host part of the URI as  the host for the WebFinger URI.

6. (moved to comment)

7. With regard to Section 8.2., I agree with Stephen that there should be some mechanism specified for users to control what information is accessible about them through WebFinger.  What's even more concerning here is that it's not even clear which servers a user should contact to control his information.  If my address is "mailto:rlb@example.com", do I just need to contact the WebFinger resources at "example.com"?  Or is it possible that there's some other WebFinger server out there serving information about my address, say "http://evil.com/.well-known/webfinger?resource=mailto%3Arlb%40example.com"?  This is another area where a tighter specification would help.

[Ballot comment]
6. In Section 5., the requirement that servers MUST send an Access-Control-Allow-Origin is kind of useless; since the server can put any value it likes in the header, it can put in something bogus, in which case it would be the same as if the header were omitted.  So the CORS requirements should either be a SHOULD, or a MUST that also requires "*".  The latter case might seem a little extreme, but it might not be unreasonable.  The server can always filter requests based on the Origin header; the only thing CORS does is push the filtering to the browser, arguably making the server less secure.

[Ballot comment]
I've been following the conversation about privacy as it relates to automatic querying of data by user agents (e.g., your mail application).  I think this is a useful and valuable function, but I have been unsatisfied by the responses that I have been seeing on the topic of how to prevent this from turning into an attack surface through which information probes can be sent.

I think this snippet illustrates the problem best:

  However, this thread is starting to head down the path of mail user
  privacy issues, not WebFinger privacy issues.  Even if we removed the
  example, it would not preclude a MUA from doing this.  And the example
  provides a very good use of WF, IMO.  It *is* functionality that I
  would like to have.  If I am so paranoid about my privacy, I would
  disable the WF feature.  If I'm paranoid that people will learn when I
  read email, I'll stop downloading images, I'll batch replies, and I
  might even set a timer to have them sent out when I'm asleep.  I'm
  just not that concerned.  When I hit send on this message, the world
  will know I'm sitting at my computer.  That's the way things work and
  I'm OK with it.                                     

The problem here is that we are being presented with a false dichotomy: no security, or disable the feature. But this doesn't address my needs. I like the idea. I want the feature. But I don't want it to turn into a privacy hole. This is very easily addressed, since it's not even a problem with webfinger per se—just a problem with how someone might _use_ webfinger. The solution: add some text to the security considerations section.  I would suggest adding some text to section 8.3:

Automatic user agents such as mail readers and web browsers SHOULD NOT automatically query webfinger on the basis of unsolicited messages received over the network. For instance, a mail reader that has the capability to query webfinger for information about the sender of an email message, such as an avatar, jabber ID, etc., SHOULD NOT issue such a query unless the message has been validated as coming from a known source, and unless the source appears on some kind of white list available to or maintained by the mail reader. Implementors are advised that merely checking the "From:" header or the "envelope from" header of an email message is definitely not sufficient validation, because such headers are easily forged in the absence of some additional validation mechanism, such as PGP, S/MIME (for per-message validation) or DKIM [RFC 6376].

I don't know if this would satisfy Stephen's concerns about privacy, but it would satisfy mine—I agree with the authors that the privacy issue is only incidentally a webfinger issue.

Oh, one last thing: I agree with Pete's DISCUSS on this: although it's fairly obvious to me what the authors intend with respect to the acct URI, it's seriously underspecified, and I don't believe that it would be obvious to every potential reader of the document. I don't have a specific action for this, so I'm not adding it as a DISCUSS, but it bears thinking about. E.g., if the _only_ transform we're expecting is s/mailto:/acct:/, then that's really easy to specify; why not specify it? If we're expecting other possible transformations, do we have any idea what they might be? Jabber IDs? I think Kerberos principals were mentioned in some conversation; are they also fair game?

[Ballot comment]
I've been following the conversation about privacy as it relates to automatic querying of data by user agents (e.g., your mail application).  I think this is a useful and valuable function, but I have been unsatisfied by the responses that I have been seeing on the topic of how to prevent this from turning into an attack surface through which information probes can be sent.

I think this snippet illustrates the problem best:

  However, this thread is starting to head down the path of mail user
  privacy issues, not WebFinger privacy issues.  Even if we removed the
  example, it would not preclude a MUA from doing this.  And the example
  provides a very good use of WF, IMO.  It *is* functionality that I
  would like to have.  If I am so paranoid about my privacy, I would
  disable the WF feature.  If I'm paranoid that people will learn when I
  read email, I'll stop downloading images, I'll batch replies, and I
  might even set a timer to have them sent out when I'm asleep.  I'm
  just not that concerned.  When I hit send on this message, the world
  will know I'm sitting at my computer.  That's the way things work and
  I'm OK with it.                                     

The problem here is that we are being presented with a false dichotomy: no security, or disable the feature. But this doesn't address my needs. I like the idea. I want the feature. But I don't want it to turn into a privacy hole. This is very easily addressed, since it's not even a problem with webfinger per se—just a problem with how someone might _use_ webfinger. The solution: add some text to the security considerations section.  I would suggest adding some text to section 8.3:

Automatic user agents such as mail readers and web browsers SHOULD NOT automatically query webfinger on the basis of unsolicited messages received over the network. For instance, a mail reader that has the capability to query webfinger for information about the sender of an email message, such as an avatar, jabber ID, etc., SHOULD NOT issue such a query unless the message has been validated as coming from a known source, and unless the source appears on some kind of white list available to or maintained by the mail reader. Implementors are advised that merely checking the "From:" header or the "envelope from" header of an email message is definitely not sufficient validation, because such headers are easily forged in the absence of some additional validation mechanism, such as PGP, S/MIME (for per-message validation) or DKIM [RFC 6376].

I don't know if this would satisfy Stephen's concerns about privacy, but it would satisfy mine—I agree with the authors that the privacy issue is only incidentally a webfinger issue.

Oh, one last thing: I agree with Pete's DISCUSS on this: although it's fairly obvious to me what the authors intend with respect to the acct URI, it's seriously underspecified, and I don't believe that it would be obvious to every potential reader of the document.  I don't have a specific action for this, so I'm not adding it as a DISCUSS, but it bears thinking about.  E.g., if the _only_ transform we're expecting is s/mailto:/acct:/, then that's really easy to specify; why not specify it?  If we're expecting other possible transformations, do we have any idea what they might be?  Jabber IDs?

[Ballot comment]
I've been following the conversation about privacy as it relates to automatic querying of data by user agents (e.g., your mail application).  I think this is a useful and valuable function, but I have been unsatisfied by the responses that I have been seeing on the topic of how to prevent this from turning into an attack surface through which information probes can be sent.

I think this snippet illustrates the problem best:

  However, this thread is starting to head down the path of mail user
  privacy issues, not WebFinger privacy issues.  Even if we removed the
  example, it would not preclude a MUA from doing this.  And the example
  provides a very good use of WF, IMO.  It *is* functionality that I
  would like to have.  If I am so paranoid about my privacy, I would
  disable the WF feature.  If I'm paranoid that people will learn when I
  read email, I'll stop downloading images, I'll batch replies, and I
  might even set a timer to have them sent out when I'm asleep.  I'm
  just not that concerned.  When I hit send on this message, the world
  will know I'm sitting at my computer.  That's the way things work and
  I'm OK with it.                                     

The problem here is that we are being presented with a false dichotomy: no security, or disable the feature. But this doesn't address my needs. I like the idea. I want the feature. But I don't want it to turn into a privacy hole. This is very easily addressed, since it's not even a problem with webfinger per se—just a problem with how someone might _use_ webfinger. The solution: add some text to the security considerations section.  I would suggest adding some text to section 8.3:

Automatic user agents such as mail readers and web browsers SHOULD NOT automatically query webfinger on the basis of unsolicited messages received over the network. For instance, a mail reader that has the capability to query webfinger for information about the sender of an email message, such as an avatar, jabber ID, etc., SHOULD NOT issue such a query unless the message has been validated as coming from a known source, and unless the source appears on some kind of white list available to or maintained by the mail reader. Implementors are advised that merely checking the "From:" header or the "envelope from" header of an email message is definitely not sufficient validation, because such headers are easily forged in the absence of some additional validation mechanism, such as PGP, S/MIME (for per-message validation) or DKIM [RFC 6376].

I don't know if this would satisfy Stephen's concerns about privacy, but it would satisfy mine—I agree with the authors that the privacy issue is only incidentally a webfinger issue.

[Ballot comment]
I've been following the conversation about privacy as it relates to automatic querying of data by user agents (e.g., your mail application).  I think this is a useful and valuable function, but I have been unsatisfied by the responses that I have been seeing on the topic of how to prevent this from turning into an attack surface through which information probes can be sent.

I think this snippet illustrates the problem best:

  However, this thread is starting to head down the path of mail user
  privacy issues, not WebFinger privacy issues.  Even if we removed the
  example, it would not preclude a MUA from doing this.  And the example
  provides a very good use of WF, IMO.  It *is* functionality that I
  would like to have.  If I am so paranoid about my privacy, I would
  disable the WF feature.  If I'm paranoid that people will learn when I
  read email, I'll stop downloading images, I'll batch replies, and I
  might even set a timer to have them sent out when I'm asleep.  I'm
  just not that concerned.  When I hit send on this message, the world
  will know I'm sitting at my computer.  That's the way things work and
  I'm OK with it.                                     

The problem here is that we are being presented with a false dichotomy: no security, or disable the feature.  But this doesn't address my needs.  I like the idea.  I want the feature.  But I don't want it to turn into a privacy hole.  This is very easily addressed, since it's not even a problem with webfinger per se—just a problem with how someone might _use_ webfinger.  The solution: add some text to the security considerations section.  I would suggest adding some text to section 8.3:

Automatic user agents such as mail readers and web browsers SHOULD NOT automatically query webfinger on the basis of unsolicited messages received over the network.  For instance, a mail reader that has the capability to query webfinger for information about the sender of an email message, such as an avatar, jabber ID, etc., SHOULD NOT issue such a query unless the message has been validated as coming from a known source, and unless the source appears on some kind of white list available to or maintained by the mail reader.  Implementors are advised that merely checking the From: header or the "envelope from" header of an email message is definitely not sufficient validation, because such headers are easily forged in the absence of some additional validation mechanism, such as PGP, S/MIME (for per-message validation) or DKIM [RFC 6376].

I don't know if this would satisfy Stephen's concerns about privacy, but it would satisfy mine—I agree with the authors that the privacy issue is only incidentally a webfinger issue.

[Ballot comment]
I've been following the conversation about privacy as it relates to automatic querying of data by user agents (e.g., your mail application).  I think this is a useful and valuable function, but I have been unsatisfied by the responses that I have been seeing on the topic of how to prevent this from turning into an attack surface through which information probes can be sent.

I think this snippet illustrates the problem best:

However, this thread is starting to head down the path of mail user
  privacy issues, not WebFinger privacy issues.  Even if we removed the
  example, it would not preclude a MUA from doing this.  And the example
  provides a very good use of WF, IMO.  It *is* functionality that I
  would like to have.  If I am so paranoid about my privacy, I would
  disable the WF feature.  If I'm paranoid that people will learn when I
  read email, I'll stop downloading images, I'll batch replies, and I
  might even set a timer to have them sent out when I'm asleep.  I'm
  just not that concerned.  When I hit send on this message, the world
  will know I'm sitting at my computer.  That's the way things work and
  I'm OK with it.                                     

The problem here is that we are being presented with a false dichotomy: no security, or disable the feature.  But this doesn't address my needs.  I like the idea.  I want the feature.  But I don't want it to turn into a privacy hole.  This is very easily addressed, since it's not even a problem with webfinger per se—just a problem with how someone might _use_ webfinger.  The solution: add some text to the security considerations section.  I would suggest adding some text to section 8.3:

Automatic user agents such as mail readers and web browsers SHOULD NOT automatically query webfinger on the basis of unsolicited messages received over the network.  For instance, a mail reader that has the capability to query webfinger for information about the sender of an email message, such as an avatar, jabber ID, etc., SHOULD NOT issue such a query unless the message has been validated as coming from a known source, and unless the source appears on some kind of white list available to or maintained by the mail reader.  Implementors are advised that merely checking the From: header or the "envelope from" header of an email message is definitely not sufficient validation, because such headers are easily forged in the absence of some additional validation mechanism, such as PGP, S/MIME (for per-message validation) or DKIM [RFC 6376].

I don't know if this would satisfy Stephen's concerns about privacy, but it would satisfy mine—I agree with the authors that the privacy issue is only incidentally a webfinger issue.

[Ballot comment]
I've been following the conversation about privacy as it relates to automatic querying of data by user agents (e.g., your mail application).  I think this is a useful and valuable function, but I have been unsatisfied by the responses that I have been seeing on the topic of how to prevent this from turning into an attack surface through which information probes can be sent.

I think this snippet illustrates the problem best:

  However, this thread is starting to head down the path of         
  mail user privacy issues, not WebFinger privacy issues.               
  Even if we removed the example, it would not preclude a                 
  MUA from doing this.  And the example provides a very good               
  use of WF, IMO.  It *is* functionality that I would like               
  to have.  If I am so paranoid about my privacy, I would                 
  disable the WF feature.  If I'm paranoid that people will               
  learn when I read email, I'll stop downloading images,             
  I'll batch replies, and I might even set a timer to have               
  them sent out when I'm asleep.  I'm just not that                         
  concerned.  When I hit send on this message, the world             
  will know I'm sitting at my computer.  That's the way
  things work and I'm OK with it.                                                         

The problem here is that we are being presented with a false dichotomy: no security, or disable the feature.  But this doesn't address my needs.  I like the idea.  I want the feature.  But I don't want it to turn into a privacy hole.  This is very easily addressed, since it's not even a problem with webfinger per se—just a problem with how someone might _use_ webfinger.  The solution: add some text to the security considerations section.  I would suggest adding some text to section 8.3:

Automatic user agents such as mail readers and web browsers SHOULD NOT automatically query webfinger on the basis of unsolicited messages received over the network.  For instance, a mail reader that has the capability to query webfinger for information about the sender of an email message, such as an avatar, jabber ID, etc., SHOULD NOT issue such a query unless the message has been validated as coming from a known source, and unless the source appears on some kind of white list available to or maintained by the mail reader.  Implementors are advised that merely checking the From: header or the "envelope from" header of an email message is definitely not sufficient validation, because such headers are easily forged in the absence of some additional validation mechanism, such as PGP, S/MIME (for per-message validation) or DKIM [RFC 6376].

I don't know if this would satisfy Stephen's concerns about privacy, but it would satisfy mine—I agree with the authors that the privacy issue is only incidentally a webfinger issue.

[Ballot discuss]
This is a really neat idea, and while the protocol specification seems reasonably solid, it's still got some pieces missing.

Specifically, the security model for this work is alluded to, but left as an exercise for the reader.  Section 6, paragraph 1, talks about authentication, but doesn't require it, nor does it define any default access control mechanism.  Paragraph 2 talks about revealing different amounts of information to different users, but doesn't explain how this would work, nor describe default behavior or a default model for deciding how such information might be filtered.

There are some good ideas expressed in section 6; what this draft needs, arguably, is one of two things:  First option, add substantial additional text describing the authentication model, the access control model and the data filtering model.  Second option, write up a separate document describing a model for how this would be done, and then reference that document from this document.  This would be preferable in my mind because such a model would be useful for more than just webfinger.  Not being knowledgable in this space, perhaps such a document already exists and could be referenced.

But without this, what we have is essentially what we had in 1977 with the finger protocol.  The state of the art has evolved significantly since then; we have Google Plus, which supports public access to restricted data, plus various levels of sharing on the basis of circles, and we have Facebook, with detailed privacy settings. These models evolved not in the abstract, but as a response to user demand.

This document addresses a need similar to that addressed by Facebook and G+ user profiles, but in a distributed fashion.  With a solid security model, I think it would be very beneficial.  So the action for this DISCUSS, if it isn't clear, is to develop a security model.  I realize that's a big ask, but without a security model I think this document is going to cause a lot of harm, or else not get used, neither of which is a desirable outcome.

[Ballot discuss]
This is a really neat idea, and while the protocol specification seems reasonably solid, it's still got some pieces missing.

Specifically, the security model for this work is alluded to, but left as an exercise for the reader.  Section 6, paragraph 1, talks about authentication, but doesn't require it, nor does it define any default access control mechanism.  Paragraph 2 talks about revealing different amounts of information to different users, but doesn't explain how this would work, nor describe default behavior or a default model for deciding how such information might be filtered.

There are some good ideas expressed in section 6; what this draft needs, arguably, is one of two things:  First option, add substantial additional text describing the authentication model, the access control model and the data filtering model.  Second option, write up a separate document describing a model for how this would be done, and then reference that document from this document.  This would be preferable in my mind because such a model would be useful for more than just webfinger.  Not being knowledgable in this space, perhaps such a document already exists and could be referenced.

But without this, what we have is essentially what we had in 1977 with the finger protocol.  The state of the art has evolved significantly since then; we have Google Plus, which supports public access to restricted data, plus various levels of sharing on the basis of circles, and we have Facebook, with detailed privacy settings.

These models evolved not in the abstract, but as a response to user demand.  This document addresses a similar need to that addressed by Facebook and G+ user profiles, but in a distributed fashion.  With a solid security model, I think it would be very beneficial.  So the action for this DISCUSS, if it isn't clear, is to develop a security model.  I realize that's a big ask, but without a security model I think this document is going to cause a lot of harm, or else not get used, neither of which is a desirable outcome.

[Ballot comment]
I've been following the conversation about privacy as it relates to automatic querying of data by user agents (e.g., your mail application).  I think this is a useful and valuable function, but I have been unsatisfied by the responses that I have been seeing on the topic of how to prevent this from turning into an attack surface through which information probes can be sent.

I think this snippet illustrates the problem best:

  However, this thread is starting to head down the path of mail   
  user privacy issues, not WebFinger privacy issues.  Even if we         
  removed the example, it would not preclude a MUA from doing             
  this.  And the example provides a very good use of WF, IMO.  It         
  *is* functionality that I would like to have.  If I am so           
  paranoid about my privacy, I would disable the WF feature.  If           
  I'm paranoid that people will learn when I read email, I'll stop         
  downloading images, I'll batch replies, and I might even set a   
  timer to have them sent out when I'm asleep.  I'm just not that         
  concerned.  When I hit send on this message, the world will know           
  I'm sitting at my computer.  That's the way things work and I'm
  OK with it.

The problem here is that we are being presented with a false dichotomy: no security, or disable the feature.  But this doesn't address my needs.  I like the idea.  I want the feature.  But I don't want it to turn into a privacy hole.  This is very easily addressed, since it's not even a problem with webfinger per se—just a problem with how someone might _use_ webfinger.  The solution: add some text to the security considerations section.  I would suggest adding some text to section 8.3:

Automatic user agents such as mail readers and web browsers SHOULD NOT automatically query webfinger on the basis of unsolicited messages received over the network.  For instance, a mail reader that has the capability to query webfinger for information about the sender of an email message, such as an avatar, jabber ID, etc., SHOULD NOT issue such a query unless the message has been validated as coming from a known source, and unless the source appears on some kind of white list available to or maintained by the mail reader.  Implementors are advised that merely checking the From: header or the "envelope from" header of an email message is definitely not sufficient validation, because such headers are easily forged in the absence of some additional validation mechanism, such as PGP, S/MIME (for per-message validation) or DKIM [RFC 6376].

I don't know if this would satisfy Stephen's concerns about privacy, but it would satisfy mine—I agree with the authors that the privacy issue is only incidentally a webfinger issue.

[Ballot discuss]
This is a really neat idea, and while the protocol specification seems reasonably solid, it's still got some pieces missing.

Specifically, the security model for this work is alluded to, but left as an exercise for the reader.  Section 6, paragraph 1, talks about authentication, but doesn't require it, nor does it define any default access control mechanism.  Paragraph 2 talks about revealing different amounts of information to different users, but doesn't explain how this would work, nor describe default behavior or a default model for deciding how such information might be filtered.

There are some good ideas expressed in section 6; what this draft needs, arguably, is one of two things:  First option, add substantial additional text describing the authentication model, the access control model and the data filtering model.  Second option, write up a separate document describing a model for how this would be done, and then reference that document from this document.  This would be preferable in my mind because such a model would be useful for more than just webfinger.  Not being knowledgable in this space, perhaps such a document already exists and could be referenced.

But without this, what we have is essentially what we had in 1977 with the finger protocol.  The state of the art has evolved significantly since then; we have Google Plus, which supports public access to restricted data, plus various levels of sharing on the basis of circles.  We have Facebook, with detailed privacy settings.  These models evolved not in the abstract, but as a response to user demand.  This document addresses much the same need that Facebook and G+ address, but in a distributed fashion.  With a solid security model, I think it would be very beneficial.  So the action for this DISCUSS, if it isn't clear, is to develop a security model.  I realize that's a big ask, but without a security model I think this document is going to cause a lot of harm, or else not get used, neither of which is a desirable outcome.

[Ballot comment]
I've been following the conversation about privacy as it relates to automatic querying of data by user agents (e.g., your mail application).  I think this is a useful and valuable function, but I have been unsatisfied by the responses that I have been seeing on the topic of how to prevent this from turning into an attack surface through which information probes can be sent.

I think this snippet illustrates the problem best:

  However, this thread is starting to head down the path of mail   
  user privacy issues, not WebFinger privacy issues.  Even if we         
  removed the example, it would not preclude a MUA from doing             
  this.  And the example provides a very good use of WF, IMO.  It         
  *is* functionality that I would like to have.  If I am so           
  paranoid about my privacy, I would disable the WF feature.  If           
  I'm paranoid that people will learn when I read email, I'll stop         
  downloading images, I'll batch replies, and I might even set a   
  timer to have them sent out when I'm asleep.  I'm just not that         
  concerned.  When I hit send on this message, the world will know           
  I'm sitting at my computer.  That's the way things work and I'm
  OK with it.

The problem here is that we are being presented with a false dichotomy: no security, or disable the feature.  But this doesn't address my needs.  I like the idea.  I want the feature.  But I don't want it to turn into a privacy hole.  This is very easily addressed, since it's not even a problem with webfinger per se—just a problem with how someone might _use_ webfinger.  The solution: add some text to the security considerations section.  I would suggest adding some text to section 8.3:

Automatic user agents such as mail readers and web browsers SHOULD NOT automatically query webfinger on the basis of unsolicited messages received over the network.  For instance, a mail reader that has the capability to query webfinger for information about the sender of an email message, such as an avatar, jabber ID, etc., SHOULD NOT issue such a query unless the message has been validated as coming from a known source, and unless the source appears on some kind of white list available to or maintained by the mail reader.  Implementors are advised that merely checking the From: header or the "envelope from" header of an email message is definitely not sufficient validation, because such headers are easily forged in the absence of some additional validation mechanism, such as PGP, S/MIME (for per-message validation) or DKIM [RFC 6376].

[Ballot discuss]
[All: As I noted earlier to the Webfinger mailing list, I have Cc'ed this to the Webfinger list along with the document authors, the document shepherd, and the rest of the IESG.

Also note that I intend to DISCUSS this until Thursday. If I get no further support from the IESG and/or the WG that this is a serious and showstopper problem, I will simply ABSTAIN on both this and on the -acct-uri document (on which I also currently have an open DISCUSS position). But it looks like Richard and I are in some agreement on this.]

There appears to be a big giant semantic gap for the client side of this protocol. I can find nothing in the document that indicates to the client how it shall determine what sort of URI to use is the resource part of the query or what the semantics of any given URI are supposed to be. I suspect that the semantics are so underspecified that there could not possibly be interoperable implementations without lots of out-of-band information.

The first example provides a mapping from an email address (or perhaps a mailto URI; that's not clear) to an acct URI, but neither the example nor anything in the rest of the document gives any clue why you would choose to query an "acct" URI based on the contents of an email message. I think the assumption is that if there is an email address, there must be some sort of "account" associated with it, and therefore querying the host on the RHS of the "@" for that account will get some interesting information. But I don't see any reason to choose an "acct" scheme over "mailto" or "smtp" or "email" or "foobar"; as far as I can tell, the choice is semantics-free.

Reading the above alongside 3.3 makes me all the more suspicious: In 3.3 (also mentioned in 4.5), a "mailto" URI gets you configuration information for all email configuration parameters. Does an "acct" URI get you configuration information for email *and* xmpp *and* sip *and* calendaring *and* all other configuration information (since you are no longer asking for a particular protocol, but rather the general account information), or do you only get "information" about the person and not their account? (I might also insert privacy and security worries here, but see Stephen's DISCUSS regarding that.) How can the client know what sort of information it can ask for and how to get it? And for that matter, how does the server tell what information to pass back? You'd think there would be a hint about this in 4.3, but "rel" only seems to provide for the client to request those things that the client already knows about it. In particular, there appears to be no way to say, "Give me user provided information, but not config information" or "Give me config information, but not blog entries".

I find the semantics for "device" in 3.4 all-the-more mysterious. As far as I can tell, this URI scheme simply means, "Give me all of the information for the entire host."

Again, the semantics of all of these interactions seem so underspecified that I don't understand how interoperation is supposed to happen.

This also leaves me with the question about why the resource query part is a URI at all. It seems to me that the resource you are asking about is not a URI (or URN) at all; it's simply an identifier for an entity that the particular host knows about. Given that, why not pass a simple identifier? (See http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ for example.) If the scheme is not providing any particular semantics about the response, I see no reason to provide the scheme. If more semantics (beyond rel) are needed, another parameter indicating the type of identifier being used seems much more appropriate than using a URI scheme.

[Ballot discuss]
Replying to a single point below from Adrian's review, which Adrian and I just discussed privately.
Thanks to Adrian for opening up my eyes on something I overlooked.
>
>
> 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.
This comment made me re-read the abstract and the introduction, and triggered some new thoughts.
They implicitly mention the query of static information, except for the sentence " for example, the amount of toner in a printer or the physical location of a server.". I overlooked the fact that the example in Section 3.4 is actually about status report. The section 3.4 title is "Retrieving Device Information", but you really mean "Retrieving Device Status Information".
And I have an OPS problem (*) with this WebFinger potential applicability to status reporting, because now, WebFinger is comparable to SNMP, polling a MIB OID to get the printer toner level.

The solution is to stress that WebFinger is targeting the query of static information (i.e. not reporting)

[Ballot comment]
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.

[Ballot discuss]
8.2

  Further, WebFinger MUST NOT be used to provide any personal data to
  any party unless explicitly authorized by the person whose
  information is being shared.

This is a usage guideline not a part of the protocol specification. At a minimum it should use non-normative language. probably it should be replaced with a description of the potential for exposure.

8.3

When discussing abuse potential, the document neglects to think about the potential for clients to reveal information about themselves based on the information that they are asking about. particularly in the context of phishing that might actually be goal of sending someone a webfinger uri. In the context of the automatic retrevial of uri's by agentts as described in 3.1, this is certainly the case.

[Ballot discuss]
1. In general, this seems like more of a "framework" document than an actual protocol.  It concerns me to put something like that on the Standards Track without some plan to add more specificity.  As the document stands, it defines a generic system for mapping an octet string to a set of attribute/value pairs.  While that level of generality can be useful for building applications, it makes it hard to evaluate the security and privacy implications.  I think this is what's at the root of Stephen's DISCUSS points on the examples.  If this were part of a working group that were chartered to define details, this would be fine as a first deliverable.  But it doesn't really seem to stand on its own.

Setting those concerns aside for the moment, I have some concerns about the interoperability of this protocol.  While the JSON body returned from a query is well specified, the process of making a query is much less so.

2. Section 4.1. does not actually tell the implementor how to construct a WebFinger URI.  A few issues/questions that need to be addressed:

2.1. What are the inputs to this process?  An "acct:" URI and optional "rel" values?

2.2. How does one choose the host part of the WebFinger URI?

2.3. The section as it currently stands allows arbitrary octet strings to be placed in the "resource" and "rel" fields.  Is that
really your intention?  It seems like these should be constrained to something like the syntax of the "source" and "rel" fields in the JRD, namely, an ASCII token or URI.

2.4. The scheme and path paragraphs from 4.2. should be moved up to this section.

3. Section 4.2. I couldn't figure out what HTTP methods a client is allowed to use.  It seems to me that it would be sensible to allow only GET, unless there is a concrete use case for something else. 

4. Section 4.5. says "use of the "acct" URI scheme is recommended, since it explicitly identifies an account accessible via WebFinger".  This does not seem compatible with what is in draft-ietf-appsawg-acct-uri, "Therefore, any protocol that uses 'acct' URIs, such as the WebFinger protocol [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol [I-D.jones-simple-web-discovery],"  Suggest removing this text.

5. In general, the use of "acct" URIs do not seem all that useful.  The only way they are used in the example use cases are (1) as a replacement for a "mailto" URI, and (2) as a "dummy" URI scheme for a "user@host" string lacking other context.  In the former case, you might as well have just used the "mailto" URI.  The latter case is kind of artificial, since the whole example is premised on the use of "acct".  It might help motivate these URIs if Section 4.1. actually used part of the resource URI to derive part of the WebFinger URI, e.g., using the host part of the URI as  the host for the WebFinger URI.

6. In Section 5., the requirement that servers MUST send an Access-Control-Allow-Origin is kind of useless; since the server can put any value it likes in the header, it can put in something bogus, in which case it would be the same as if the header were omitted.  So the CORS requirements should either be a SHOULD, or a MUST that also requires "*".  The latter case might seem a little extreme, but it might not be unreasonable.  The server can always filter requests based on the Origin header; the only thing CORS does is push the filtering to the browser, arguably making the server less secure.

7. With regard to Section 8.2., I agree with Stephen that there should be some mechanism specified for users to control what information is accessible about them through WebFinger.  What's even more concerning here is that it's not even clear which servers a user should contact to control his information.  If my address is "mailto:rlb@example.com", do I just need to contact the WebFinger resources at "example.com"?  Or is it possible that there's some other WebFinger server out there serving information about my address, say "http://evil.com/.well-known/webfinger?resource=mailto%3Arlb%40example.com"?  This is another area where a tighter specification would help.

[Ballot discuss]
1. In general, this seems like more of a "framework" document than an actual protocol.  It concerns me to put something like that on the Standards Track without some plan to add more specificity.  As the document stands, it defines a generic system for mapping an octet string to a set of attribute/value pairs.  While that level of generality can be useful for building applications, it makes it hard to evaluate the security and privacy implications.  I think this is what's at the root of Stephen's DISCUSS points on the examples.  If this were part of a working group that were chartered to define details, this would be fine as a first deliverable.  But it doesn't really seem to stand on its own.

Setting those concerns aside for the moment, I have some concerns about the interoperability of this protocol.  While the JSON body returned from a query is well specified, the process of making a query is much less so.

2. Section 4.1. does not actually tell the implementor how to construct a WebFinger URI.  A few issues/questions that need to be addressed:
2.1. What are the inputs to this process?  An "acct:" URI and optional "rel" values?
2.2. How does one choose the host part of the WebFinger URI?
2.3. The section as it currently stands allows arbitrary octet strings to be placed in the "resource" and "rel" fields.  Is that really your intention?  It seems like these should be constrained to something like the syntax of the "source" and "rel" fields in the JRD, namely, an ASCII token or URI.
2.4. The scheme and path paragraphs from 4.2. should be moved up to this section.

3. Section 4.2. I couldn't figure out what HTTP methods a client is allowed to use.  It seems to me that it would be sensible to allow only GET, unless there is a concrete use case for something else. 

4. Section 4.5. says "use of the "acct" URI scheme is recommended, since it explicitly identifies an account accessible via WebFinger".  This does not seem compatible with what is in draft-ietf-appsawg-acct-uri, "Therefore, any protocol that uses 'acct' URIs, such as the WebFinger protocol [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol [I-D.jones-simple-web-discovery],"  Suggest removing this text.

5. In general, the use of "acct" URIs do not seem all that useful.  The only way they are used in the example use cases are (1) as a replacement for a "mailto" URI, and (2) as a "dummy" URI scheme for a "user@host" string lacking other context.  In the former case, you might as well have just used the "mailto" URI.  The latter case is kind of artificial, since the whole example is premised on the use of "acct".  It might help motivate these URIs if Section 4.1. actually used part of the resource URI to derive part of the WebFinger URI, e.g., using the host part of the URI as  the host for the WebFinger URI.

6. In Section 5., the requirement that servers MUST send an Access-Control-Allow-Origin is kind of useless; since the server can put any value it likes in the header, it can put in something bogus, in which case it would be the same as if the header were omitted.  So the CORS requirements should either be a SHOULD, or a MUST that also requires "*".  The latter case might seem a little extreme, but it might not be unreasonable.  The server can always filter requests based on the Origin header; the only thing CORS does is push the filtering to the browser, arguably making the server less secure.

7. With regard to Section 8.2., I agree with Stephen that there should be some mechanism specified for users to control what information is accessible about them through WebFinger.  What's even more concerning here is that it's not even clear which servers a user should contact to control his information.  If my address is "mailto:rlb@example.com", do I just need to contact the WebFinger resources at "example.com"?  Or is it possible that there's some other WebFinger server out there serving information about my address, say "http://evil.com/.well-known/webfinger?resource=mailto%3Arlb%40example.com"?  This is another area where a tighter specification would help.

[Ballot discuss]
As will be seen, I (still) have issues with the privacy
aspects of this specification. Some of those are most
apparent through the use-cases/examples so I've taken the
unusal step of DISCUSSing those since they really seem to
convey the real intent of this protocol. To an extent, some
of the suggested changes there do represent personal
preferences of mine but I believe that the DISCUSSion is
still worth having between the authors and IESG and perhaps
the WG.

(1) 3.1, having the MUA automatically do the webfinger thing
is a privacy disaster and would cause MUAs to visit sources
of spam continually and to expose the email addresses of
their correspondents. Other references to having a UA
automatically do webfinger also need to be deleted kind of
behaviour needs to be the subject of a "MUST NOT" statement
IMO. In fact, it already is, since 8.2 says: "WebFinger MUST
NOT be used to provide any personal data to any party unless
explicitly authorized by the person whose information is
being shared." Having a MUA automatically send out a WF
request where the query target is the mail sender/from
contradicts this requirement. The 3.1 example also fits the
anti-pattern given in 8.3. Suggested fix, easy: say that a
MUA MUST NOT do the automatic thing, as per 8.2, which would
be a fine forward reference.

(2) 3.3, this example is odd - why should Sue expose her
username in this interaction - there's no occurrence of
anything clearly user-dependent in the response except what
was given in the request. Why should we expose user
information unnecessarily in this manner? I think the fix
here is for user Sue to send a request for "anon@example.com"
and for the text to specifically say that making use of the
real username isn't a good plan and making use of an invented
non-existent string for username in this case is a fine plan
and perhaps even specifying such a "nonexistent" username
value that can be supported by and understood by all clients
and servers and saying when it'd be sensible to use that.

(3) 3.4, making devices discoverable like this, esp if device
type and firmware revisions were to be exposed represents a
significant increase in an existing risk.  (We had a recent
discussion related to vCard for a similar use case.) This
section seems to be too speculative to be honest, so I'd
suggest just deleting it. If not, maybe add text like that
added in the vCard case.

(4) 4.2, can you explain the security consdiderations
associated with re-directing a client from
https://example.com to https://example.net? Why don't you
need to do that explicitly in the document? I think you might
need to explicitly say that in re-direct cases, both sessions
MUST be good TLS sessions or else clients might well accept
3xx from a MITM.  Are there no requirements to compare the
original request and final response? (I could buy that but
want to check.)

(5) 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?


(6) 8.3: A possible missing security consideration - I think
it'd be good if this section said that WF servers SHOULD
implement mitigations against harvesting or overuse of
WF, perhaps via rate controls or other mechanisms.

[Ballot comment]
- 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.

[Ballot discuss]

As will be seen, I (still) have issues with the privacy
aspects of this specification. Some of those are most
apparent through the use-cases/examples so I've taken the
unusal step of DISCUSSing those since they really seem to
convey the real intent of this protocol. To an extent, some
of the suggested changes there do represent personal
preferences of mine but I believe that the DISCUSSion is
still worth having between the authors and IESG and perhaps
the WG.

(1) 3.1, having the MUA automatically do the webfinger thing
is a privacy disaster and would cause MUAs to visit sources
of spam continually and to expose the email addresses of
their correspondents. Other references to having a UA
automatically do webfinger also need to be deleted kind of
behaviour needs to be the subject of a "MUST NOT" statement
IMO. In fact, it already is, since 8.2 says: "WebFinger MUST
NOT be used to provide any personal data to any party unless
explicitly authorized by the person whose information is
being shared." Having a MUA automatically send out a WF
request where the query target is the mail sender/from
contradicts this requirement. The 3.1 example also fits the
anti-pattern given in 8.3. Suggested fix, easy: say that a
MUA MUST NOT do the automatic thing, as per 8.2, which would
be a fine forward reference.

(2) 3.3, this example is odd - why should Sue expose her
username in this interaction - there's no occurrence of
anything clearly user-dependent in the response except what
was given in the request. Why should we expose user
information unnecessarily in this manner? I think the fix
here is for user Sue to send a request for "anon@example.com"
and for the text to specifically say that making use of the
real username isn't a good plan and making use of an invented
non-existent string for username in this case is a fine plan
and perhaps even specifying such a "nonexistent" username
value that can be supported by and understood by all clients
and servers and saying when it'd be sensible to use that.

(3) 3.4, making devices discoverable like this, esp if device
type and firmware revisions were to be exposed represents a
significant increase in an existing risk.  (We had a recent
discussion related to vCard for a similar use case.) This
section seems to be too speculative to be honest, so I'd
suggest just deleting it. If not, maybe add text like that
added in the vCard case.

(4) 4.2, can you explain the security consdiderations
associated with re-directing a client from
https://example.com to https://example.net? Why don't you
need to do that explicitly in the document? I think you might
need to explicitly say that in re-direct cases, both sessions
MUST be good TLS sessions or else clients might well accept
3xx from a MITM.  Are there no requirements to compare the
original request and final response? (I could buy that but
want to check.)

(5) 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?

[Ballot comment]

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

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-appsawg-webfinger-10.  Authors should review
the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We understand that, upon approval of this document, there are two actions which we need to complete.

First, in the Well Known URIs registry located at:

http://www.iana.org/assignments/well-known-uris/well-known-uris.xml

a new well-known URI is to be registered as follows:

URI Suffix: webfinger
Change Controller: IETF
Reference: [ RFC-to-be ]

NOTE: The request has been reviewed and approved by Mark Nottingham,
the expert, via ticket 666439.  We are working on that ticket.

Second, in the Application Media Type registry located at:

http://www.iana.org/assignments/media-types/application

a new application media type is to be registered as follows:

jrd+json

We understand that these actions are the only ones that need to be
completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (WebFinger) to Proposed Standard


The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'WebFinger'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-03-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This specification defines the WebFinger protocol, which can be used
  to discover information about people or other entities on the
  Internet using standard HTTP methods.  WebFinger discovers
  information for a URI that might not be usable as a locator
  otherwise, such as account or email URIs.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/


No IPR declarations have been submitted directly on this I-D.

AD review of version -10:

This document's in good shape, and is really good work.  Thanks,
everyone.  I only have one significant issue, and a bunch of minor
comments.

---------------------------------------------
One significant issue:

In Section 4.3:
  In the event that a client requests link relation types that are not
  defined for the specified "resource", a resource descriptor MUST be
  returned.  In the returned JRD, the "links" array MAY be absent,
  empty, or contain only links that did match a provided "rel" value.

I don't understand what this is trying to tell me to do, if I'm
implementing a WebFinger resource and I get inappropriate "rel"
values.  I'm guessing that this is what you want, but this text
doesn't make that clear at all:

1. Ignore all "rel" values that contain link relation types that
are not defined for the specified resource.
2. If there are other "rel" values left, filter on them as though
they were the only ones present.
3. If there are *no* other "rel" values left, do *not* return an
unfiltered JRD.  Instead, either:
3a. ...return a JRD with an empty "links" array ("links" : [ ]), or
3b. ...return a JRD with no "links" array present at all.

Is there a reason to allow both 3a and 3b, rather than specifying
one or the other?

In any case, please re-word this paragraph so it says clearly
what you want it to say.

---------------------------------------------
Other minor comments:

In the last paragraph of Section 3.2, you have "OPTIONAL".  The
2119 keyword is out of place in this non-normative example.
Besides: it's not optional; it's a "SHOULD support".  So, really,
change "is OPTIONAL" to "is not guaranteed".

In the first paragraph of Section 4, to be consistent with how
you render things later, you should probably make these changes
(and then make sure your use of this is consistent throughout the
document):

  using the HTTPS scheme => using the "https" scheme

  other URI scheme (such as HTTP) ==> other URI scheme (such as "http")

In Section 4:
  GET requests to a WebFinger resource convey the URI to perform the
  query upon in the URI's query string; see Section 4.1 for details.

First, I find this to be an awkward, with two different URIs not
clearly differentiated.  Second, Section 4.1 doesn't actually
give details of the "URI to perform the query upon".  Maybe
this?:

NEW
  A WebFinger resource is always given a query target, which is
  another URI that identifies the entity whose information is
  sought.  GET requests to a WebFinger resource convey the query
  target in the "resource" parameter in the WebFinger URI's query
  string; see Section 4.1 for details.
END

In Section 4.1:
  First, each parameter value is percent-encoded, as
  per Section 2.1 of RFC 3986, so that it conforms to the query
  production in Section 3.4 of that specification, and additionally any
  instances of the "=" and "&" characters are also percent-encoded.

I think this would be a bit clearer this way:

NEW
  First, each parameter value is percent-encoded, as
  per Section 2.1 of RFC 3986.  The encoding is done to conform to
  the query production in Section 3.4 of that specification, with the
  addition that any instances of the "=" and "&" characters within the
  parameter value are also percent-encoded.
END

I think that will avoid anyone's trying to encode the "=" in
"resource=", and the like.

  The order in which the client places each
  attribute-and-value pair within the query component is unspecified.

Is that really trying to say that the order has to be treated as
insignificant when the query component is interpreted?  If so, it
should say it that way:

NEW
  The order in which the client places each
  attribute-and-value pair within the query component does not matter
  in the interpretation of the query component.
END

In Section 4.2:
  The client MAY include the "Accept"
  header to indicate a desired representation, though no other
  representation than JRD is defined in this specification.

I think I might prefer this:

NEW
  The client MAY include the "Accept"
  header to indicate a desired representation; representations
  other than JRD might be defined in future specifications.  The
  WebFinger resource MUST silently ignore any requested
  representations that it does not understand and support.
END

  A WebFinger resource MAY redirect the client, but MUST only redirect
  the client to an HTTPS URI.

I don't think this will actually be misinterpreted, but just to
be clear about the MAY/MUST thing:

NEW
  A WebFinger resource MAY redirect the client; if it does, the
  redirection MUST only be to an "https" URI.
END

In Section 4.3:
  When the "rel" parameter is used, only the link relations
  that match the link relations provided via the "rel" parameter are
  included in the array of links returned in the JRD.

Not when it's *used* -- it can be used, but the resource might
not support it, right?  So:

NEW
  When the "rel" parameter is used and accepted, only the link
  relations that match the link relations provided via the "rel"
  parameter are included in the array of links returned in the JRD.
END

  The "rel" parameter MAY be transmitted to the WebFinger resource
  multiple times in order to request multiple types of link relations.

Does this really mean this?:

NEW
  The "rel" parameter MAY be included in the query component of the
  WebFinger URI multiple times in order to request multiple types of
  link relations.
END

Actually, I think "in the query component of the WebFinger URI"
can be removed, to just say, "MAY be included multiple times".

In Section 4.4, you've hit a pedantic pet peeve of mine that's a
lost cause that I still fight:

  a JSON object that is comprised of the following

Correctly, the whole "comprises" the parts (or "is composed of",
but not "is comprised of").

NEW
  a JSON object that comprises the following
END

And similarly in the following paragraph and in Sections 4.4.3,
4.4.4.4, and 4.4.4.5.

In Section 4.5:
  WebFinger requests can include a "resource" parameter (see Section
  4.1) specifying the URI of an account, device, or other entity.

Not "can include"; they do include it: Section 4.2 says that the
'query component MUST include the "resource" parameter exactly
once'.

  To perform a WebFinger lookup on an account specific to the host
  being queried, use of the "acct" URI scheme is RECOMMENDED, since it
  explicitly identifies an account accessible via WebFinger.

I'm racking my brain, trying to decide whether this is an
appropriate 2119 "RECOMMENDED", which means "SHOULD", which means
that there's an interoperability reason why you must do this
unless you fully understand the consequences of not doing it.

If what you're saying is that "acct" is always guaranteed to
work, while others, such as "mailto" are crap shoots, then I
think "RECOMMENDED" is OK.  But if they all might or might not
work, and we're just saying that "acct" was made for this and
we're encouraging its use and it's the best of the bunch, then
that's not a 2119 "RECOMMENDED".

So can you clarify this for me (in email; don't change the text yet)?

In Section 6:
  As with all web resources, access to the WebFinger resource MAY
  require authentication.  Further, failure to provide required
  credentials MAY result in the server forbidding access or providing a
  different response than had the client authenticated with the server.

Neither of these "MAY"s is an appropriate 2119 key word.  "MAY"
means "this is a completely optional choice".  The WebFinger
resource will either require authentication or it won't, but
that's not a MAY sort of choice for anyone.  Make both of them
"may", or perhaps "might" or "could".

Just as a contrast, the MAY in the second paragraph is fine,
because it really is describing a choice that the resource can
make, at its option.

In the third paragraph, it's less clear.  Given the example you
use, I'd remove the "MAY".  But I'm not going to beat you with
truncheons about that one.

In Section 8:
On the two paragraphs about private/personal information, I
suggest explicitly passing that by Alissa Cooper for review and
comment, if you haven't already.

Section 9.1:
It would be good to explicitly request review on the
mailing list now.  That could
save time for the formality later.

---------------------------------------------

Alternate Document Writeup

1. Summary

Draft name: "WebFinger" draft-ietf-appsawg-webfinger-10.txt

Salvatore Loreto is the document shepherd

Barry Leiba is the responsible Area Director


Draft Abstract:
" This specification defines the WebFinger protocol, which can
be used to discover information about people or other entities on the
Internet
using standard HTTP methods. WebFinger discovers information
for a URI that might not be usable as a locator otherwise, such as
account or email URIs."




2. Review and Consensus

The "WebFinger" draft has been discussed extensively within the
APPSAwg during the last year, it become a wg item in August 2012.
Actually at some point the mail traffic generated by the
discussion was so high that it was agreed to move the discussion to a
dedicated mailing list
(webfinger@ietf.org).

The only significant point difficult to agree on has been about
"whether WebFinger MUST support HTTPS only or instead it should be
allowed for WebFinger
fallback from HTTPS to HTTP". That was resolved with a
consensus call that generated a strong rough consensus for HTTPS only.

The draft has been also extensively reviewed during the APPSAwg
Last Call. A lot of editorial issues, text clarifications have been
raised; all of them are now
addressed in the current version of the draft. During the wglc
process it has been also agreed to define a new media type for WebFinger.

There are several open source WebFinger implementations already
updated to the last version of the draft, a not exhaustive list of them
can be found here:
http://www.packetizer.com/webfinger/software.html


3. Intellectual Property

All the authors have confirmed conformance with BCPs 78 and 79.


4. Other Points

The draft reference as Normative:
- RFC 4627, "The application/json Media Type for JavaScript
Object Notation"
- RFC 2818, "HTTP over TLS"
those appear in the DOWNREF registry.

There is an Unused reference: [15] Klyne, G., Newman, C., "Date
and Time on the Internet:
Timestamps", RFC 3339, July 2002.

There is no new IANA registry created by this document.