Subject: [webfinger] Preparing for next revision of the WebFinger spec

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 21 May 2013 22:03:40 -0400

Folks,

It has been a while since we updated the WebFinger spec.  I was out of the
office for a while and so things had to be put on hold.

We still have a number of DISCUSS items.  However, before we get back to
those, I'd like to address issues raised with the current published draft.
I took noted as folks made comments.  I'd like to run through each of those
and suggest a text change.  If we can get agreement, I'll make those
changes, publish revised text, and then we can go back to the additional
open DISCUSS items.

ITEM 1
------
Section 4, paragraph leading with "The host to which a WebFinger query is
issued is significant."  I think the intent was good and guidance is right
in general, but some expressed concern.  If I recall the concern, it was
that local policy might conflict with these stated procedures.  For example,
one might design an application that performs WF queries and targets a
specific host, regardless of the "host" part.  I have no strong opinion on
this one, but if there are use cases where not following the guidance of
this paragraph is problematic, then we should consider removing it.  I see
this as no different than what most applications do: they would usually
direct queries to the specified host, but might have local policies that
specify a different result.  For example, my MTA would usually try to
deliver mail to the specified host, but I can specify a "smart host" that
receives all mail.  Likewise, I can use a proxy with my browser for HTTP
requests.  What does the group want?  Keep it, remove it, or does someone
have specific changes they would like to see?

ITEM 2
------
Last paragraph of Section 4.2 introduces the HEAD method.  That was never
discussed before and, the more I think about it, the less I think we should
say anything.  The HTTP spec already provides guidance on this issue.  HEAD
is required for general purpose web servers, but not otherwise.  The server
can definitely control whether the client will ever even use HEAD by
managing the cache headers properly.  This is all HTTP stuff, not something
we need to go into in the WF spec, IMO.  I suggest we remove that paragraph.

ITEM 3
------
Section 4.4.1, we require "subject" to be present, but it was raised on the
list that this is not in line with RFC 6415 and the XRD spec.  I agree and
we should change the MUST to SHOULD.

ITEM 4
------
Section 4.4.4.4, we specify using "default" to signify that language is not
specified, but folks pointed out that ISO and IETF specs both specify "und"
for this, including the RFC referenced right in the first paragraph.  RFC
6415 used "default", thus we did here.  To not perpetuate an error, I
suggest we change this to "und", as suggested by experts on the list.  I'm
not sure what to do about the RFC 6415 discrepancy, but I would say it is an
error that happened because the WG did not review the text.  We should
submit and errata against RFC 6415 on the grounds that it failed to adhere
to the relevant RFC.  Thoughts?

ITEM 5
------
Few changes in 8.2 that were fully hashed on the list, so I think we're good
to go on these.  Nonetheless, I want to enumerate them before I publish the
changes.  Those changes are:
    o Removal of the last sentence of the first paragraph of 8.2
    o Also in 8.2, changing "WebFinger MUST NOT be used to provide any
      personal data to any party unless explicitly authorized by the person
      whose information is being shared" changed to "WebFinger MUST NOT be
      used to provide any personal data unless publishing that data via
      WebFinger by the relevant service was explicitly authorized by the
      person whose information is being shared"

That's it for now, unless folks are aware of other items raised outside of
the DISCUSS items.  If we can close on these 5, I'll update the draft and we
can go back to the other DISCUSS items.

Paul

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 23 May 2013 09:59:00 +0200

On Tue, May 21, 2013 at 10:03:40PM -0400,
 Paul E. Jones <[email-masked]> wrote 
 a message of 82 lines which said:

> ITEM 4 [...] To not perpetuate an error, I suggest we change this to
> "und", as suggested by experts on the list. [...] We should submit
> and [sic] errata against RFC 6415 on the grounds that it failed to
> adhere to the relevant RFC.  Thoughts?

I fully agree with these two actions.

---

From: Mike Jones <[email-masked]>
Date: Thu, 23 May 2013 22:26:54 +0000

Item 1 - I would back out this change or reword it because it has unintended consequences.  I have an account named [email-masked] at Facebook.  I have one named [email-masked] at Google.  It must be legal to query for acct:[email-masked] at google.com and at facebook.com, or information about those accounts could not be discovered.  (I can work on specific wording with you if you want to keep parts of this change, rather than just backing it out.)

Item 2 - We should say nothing about HEAD since HTTP already specifies its behavior.  Please delete the new text.

Item 3 - I'm fine with SHOULD.

Item 4 - We should change to the standard identifier "und".  I'm also fine with an errata being filed against RFC 6415.

Item 5 - I'm fine with these changes.

Thanks for working to move this forward.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul E. Jones
Sent: Tuesday, May 21, 2013 7:04 PM
To: [email-masked]
Subject: [webfinger] Preparing for next revision of the WebFinger spec

Folks,

It has been a while since we updated the WebFinger spec.  I was out of the office for a while and so things had to be put on hold.

We still have a number of DISCUSS items.  However, before we get back to those, I'd like to address issues raised with the current published draft.
I took noted as folks made comments.  I'd like to run through each of those and suggest a text change.  If we can get agreement, I'll make those changes, publish revised text, and then we can go back to the additional open DISCUSS items.

ITEM 1
------
Section 4, paragraph leading with "The host to which a WebFinger query is issued is significant."  I think the intent was good and guidance is right in general, but some expressed concern.  If I recall the concern, it was that local policy might conflict with these stated procedures.  For example, one might design an application that performs WF queries and targets a specific host, regardless of the "host" part.  I have no strong opinion on this one, but if there are use cases where not following the guidance of this paragraph is problematic, then we should consider removing it.  I see this as no different than what most applications do: they would usually direct queries to the specified host, but might have local policies that specify a different result.  For example, my MTA would usually try to deliver mail to the specified host, but I can specify a "smart host" that receives all mail.  Likewise, I can use a proxy with my browser for HTTP requests.  What does the group want?  Keep it, remove it, or does someone have specific changes they would like to see?

ITEM 2
------
Last paragraph of Section 4.2 introduces the HEAD method.  That was never discussed before and, the more I think about it, the less I think we should say anything.  The HTTP spec already provides guidance on this issue.  HEAD is required for general purpose web servers, but not otherwise.  The server can definitely control whether the client will ever even use HEAD by managing the cache headers properly.  This is all HTTP stuff, not something we need to go into in the WF spec, IMO.  I suggest we remove that paragraph.

ITEM 3
------
Section 4.4.1, we require "subject" to be present, but it was raised on the list that this is not in line with RFC 6415 and the XRD spec.  I agree and we should change the MUST to SHOULD.

ITEM 4
------
Section 4.4.4.4, we specify using "default" to signify that language is not specified, but folks pointed out that ISO and IETF specs both specify "und"
for this, including the RFC referenced right in the first paragraph.  RFC
6415 used "default", thus we did here.  To not perpetuate an error, I suggest we change this to "und", as suggested by experts on the list.  I'm not sure what to do about the RFC 6415 discrepancy, but I would say it is an error that happened because the WG did not review the text.  We should submit and errata against RFC 6415 on the grounds that it failed to adhere to the relevant RFC.  Thoughts?

ITEM 5
------
Few changes in 8.2 that were fully hashed on the list, so I think we're good to go on these.  Nonetheless, I want to enumerate them before I publish the changes.  Those changes are:

That's it for now, unless folks are aware of other items raised outside of the DISCUSS items.  If we can close on these 5, I'll update the draft and we can go back to the other DISCUSS items.

Paul

_______________________________________________
webfinger mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/webfinger

---

From: John Bradley <[email-masked]>
Date: Thu, 23 May 2013 19:04:07 -0400

I agree with Mike's comments.

On item 1 As an example the OIDF Account Chooser WG is deploying a HTML5 UI for people to tell RP what there account and Identity provider are.  That is required because as Mike points out people use email addresses from one service as there account_id at another service.  If a website is told by my agent that my account is [email-masked] with a host of google.com it should not be precluded from using WF to look it up at google.

There are basically 3 possibilities.
1 The site has some admin policy to look everything up at a trusted WF proxy 
2 The WF client has been told that the account is at some host that is not the domain portion of the account URI (Account chooser or some other method.
3 The WF client gets account identifier with no additional provider info and has no admin policy and considers the domain to be authoritative for the WF server to use.

3 is probably the most common but the first two are also valid uses.

John B.

On 2013-05-23, at 6:26 PM, Mike Jones <[email-masked]> wrote:

> Section 4, paragraph leading with "The host to which a WebFinger query is issued is significant."  I think the intent was good and guidance is right in general, but some expressed concern.  If I recall the concern, it was that local policy might conflict with these stated procedures.  For example, one might design an application that performs WF queries and targets a specific host, regardless of the "host" part.  I have no strong opinion on this one, but if there are use cases where not following the guidance of this paragraph is problematic, then we should consider removing it.  I see this as no different than what most applications do: they would usually direct queries to the specified host, but might have local policies that specify a different result.  For example, my MTA would usually try to deliver mail to the specified host, but I can specify a "smart host" that receives all mail.  Likewise, I can use a proxy with my browser for HTTP requests.  What does the group want
> ?  Keep it, remove it, or does someone have specific changes they would like to see?
> 
> ITEM 2
> ------