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

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 24 May 2013 15:55:22 -0400

Richard,

I think it may have been you who was most interested in Item 1 (see the
reference to Item 1 down below).

Do you want to keep something like this in the spec or can we remove that
whole paragraph?  Mike has offered to re-word it, but I think your guidance
would be best.

Paul

> -----Original Message-----
> From: Mike Jones [mailto:[email-masked]]
> Sent: Thursday, May 23, 2013 6:27 PM
> To: Paul E. Jones; [email-masked]
> Subject: RE: [webfinger] Preparing for next revision of the WebFinger spec
> 
> 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:
>     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
> 
> 
> _______________________________________________
> webfinger mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webfinger

---

From: Mike Jones <[email-masked]>
Date: Fri, 24 May 2013 21:11:32 +0000

s/has been configured/knows/ and I'm good with it.  ("Configured" sounds static, whereas "knows" is more dynamic, which is often likely to be the actual case.)

I'd also suggest this change for generality: s/local policy/additional information that it has/ - again, more dynamic in nature.

                                                                -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Friday, May 24, 2013 1:08 PM
To: Paul E. Jones
Cc: Mike Jones; [email-masked]
Subject: Re: FW: [webfinger] Preparing for next revision of the WebFinger spec

Hey Paul,

Thanks for the heads-up on this.

I would argue that this is like HTTP.  If I hand you an HTTP URI to look up, by default the host you connect to is the one in the URI.  But if you're UA is configured to use a proxy, you connect to that host.  So what we want is a carve-out from the MUST to cover cases where there's explicit direction to go elsewhere.  Proposed text:

"""
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, unless the client has been configured through some out-of-band mechanism to send the query to another host. 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.
"""

In other words: "unless the client has been configured through some out-of-band mechanism to send the query to another host"

Hope this helps,
--Richard

On Fri, May 24, 2013 at 3:55 PM, Paul E. Jones <[email-masked]<mailto:[email-masked]>> wrote:
Richard,

Paul

> From: Mike Jones [mailto:[email-masked]<mailto:[email-masked]>]
> To: Paul E. Jones; [email-masked]<mailto:[email-masked]>
> unintended consequences.  I have an account named [email-masked]<mailto:[email-masked]> at
> Facebook.  I have one named [email-masked]<mailto:[email-masked]> at Google.  It must be legal
> to query for acct:[email-masked]<mailto:[email-masked]> at google.com<http://google.com> and at facebook.com<http://facebook.com>, or
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> Behalf Of Paul E. Jones
> To: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 24 May 2013 16:07:51 -0400

Hey Paul,

I would argue that this is like HTTP.  If I hand you an HTTP URI to look
up, by default the host you connect to is the one in the URI.  But if
you're UA is configured to use a proxy, you connect to that host.  So what
we want is a carve-out from the MUST to cover cases where there's explicit
direction to go elsewhere.  Proposed text:

"""
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, unless the client has been configured through
some out-of-band mechanism to send the query to another host. 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.
"""

In other words: "unless the client has been configured through some
out-of-band mechanism to send the query to another host"

Hope this helps,
--Richard

---

From: Richard Barnes <[email-masked]>
Date: Sat, 25 May 2013 16:28:31 -0400

You know, Mike, software hates to be anthropomorphized ;)

So I'm ok with changing words, but might prefer something like "has
external information" to "knows".

On Friday, May 24, 2013, Mike Jones wrote:

>  s/has been configured/knows/ and I’m good with it.  (“Configured” sounds
> static, whereas “knows” is more dynamic, which is often likely to be the
> actual case.)****
>
> ** **
>
> I’d also suggest this change for generality: s/local policy/additional
> information that it has/ – again, more dynamic in nature.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* Richard Barnes [mailto:[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>]
> *Sent:* Friday, May 24, 2013 1:08 PM
> *To:* Paul E. Jones
> *Cc:* Mike Jones; [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>
> *Subject:* Re: FW: [webfinger] Preparing for next revision of the
> WebFinger spec****
>
> ** **
>
> Hey Paul,****
>
> ** **
>
> Thanks for the heads-up on this.****
>
> ** **
>
> direction to go elsewhere.  Proposed text:****
>
> ** **
>
> """****
>
> 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, unless the client has been configured
> through some out-of-band mechanism to send the query to another host. 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.****
>
> """****
>
> ** **
>
> out-of-band mechanism to send the query to another host"****
>
> ** **
>
> Hope this helps,****
>
> --Richard****
>
> ** **
>
> ** **
>
> ** **
>
> On Fri, May 24, 2013 at 3:55 PM, Paul E. Jones <[email-masked]>
> wrote:****
>
> Richard,
>
> > To:

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 26 May 2013 19:18:14 -0400

Guys,

OK, I think we're converging

I used "unless the client receives instructions through some out-of-band
mechanism to send the query to another host" and ".to which it directs the
query using additional information it has."

Paul

From: Richard Barnes [mailto:[email-masked]] 
Sent: Saturday, May 25, 2013 4:29 PM
To: Mike Jones
Cc: Paul E. Jones; [email-masked]
Subject: Re: FW: [webfinger] Preparing for next revision of the WebFinger
spec

So I'm ok with changing words, but might prefer something like "has external
information" to "knows".  

s/has been configured/knows/ and I'm good with it.  ("Configured" sounds
static, whereas "knows" is more dynamic, which is often likely to be the
actual case.)

I'd also suggest this change for generality: s/local policy/additional
information that it has/ - again, more dynamic in nature.

                                                                -- Mike

From: Richard Barnes [mailto:[email-masked]
<javascript:_e(%7b%7d,%20'cvml',[email-masked]');> ] 
Sent: Friday, May 24, 2013 1:08 PM
To: Paul E. Jones
Cc: Mike Jones; [email-masked]
<javascript:_e(%7b%7d,%20'cvml',[email-masked]');> 
Subject: Re: FW: [webfinger] Preparing for next revision of the WebFinger
spec

Hey Paul,

I would argue that this is like HTTP.  If I hand you an HTTP URI to look up,
by default the host you connect to is the one in the URI.  But if you're UA
is configured to use a proxy, you connect to that host.  So what we want is
a carve-out from the MUST to cover cases where there's explicit direction to
go elsewhere.  Proposed text:

"""

"""

Hope this helps,

--Richard

wrote:

Richard,

Paul

---

From: John Bradley <[email-masked]>
Date: Sun, 26 May 2013 21:37:33 -0400

Fine as long as a WF client being told explicitly the account identifier at Google or some other WF host is [email-masked] and being allowed to resolve that.

The notion that the domain part of an email address is always the authoritative server is wrong.   As Mike points out many sites include an @domain as part of the account name.

We don't have any good way to represent that with acct URI.   I guess we could have used acct:[email-masked]@google.com, but that probably would have confused people in itself.

For things like account chooser which pass the account name and host separately to deal with this issue we still want the WF client to do something sensible.

So would passing the account and host separately be considers out of band?

John B.

On 2013-05-26, at 7:18 PM, "Paul E. Jones" <[email-masked]> wrote:

> Guys,
>  
> OK, I think we’re converging
>  
> I used “unless the client receives instructions through some out-of-band mechanism to send the query to another host” and “…to which it directs the query using additional information it has.”
>  
> Paul
>  
> So I'm ok with changing words, but might prefer something like "has external information" to "knows".  
> 
> s/has been configured/knows/ and I’m good with it.  (“Configured” sounds static, whereas “knows” is more dynamic, which is often likely to be the actual case.)
>  
> I’d also suggest this change for generality: s/local policy/additional information that it has/ – again, more dynamic in nature.
>  
>                                                                 -- Mike
>  
> On Fri, May 24, 2013 at 3:55 PM, Paul E. Jones <[email-masked]> wrote:
> 
> Richard,
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 26 May 2013 20:07:47 -0600

On 5/26/13 7:37 PM, John Bradley wrote:
> Fine as long as a WF client being told explicitly the account identifier
> at Google or some other WF host is [email-masked]
> <mailto:[email-masked]> and being allowed to resolve that.
> 
> The notion that the domain part of an email address is always the
> authoritative server is wrong.   As Mike points out many sites include
> an @domain as part of the account name.
> 
> We don't have any good way to represent that with acct URI.   I guess we
> could have used acct:[email-masked]@google.com
> <mailto:[email-masked]>, but that probably would have confused
> people in itself.

Standard percent-encoding rules from RFC 3986 allow this:

acct:[email-masked]

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: John Bradley <[email-masked]>
Date: Sun, 26 May 2013 22:44:48 -0400

That is helpfull.

So if a WF client is handed two parts account  and Domain would it be expected to concatenate those into a acct: URI and pass acct:[email-masked]@google.com to the .well-known at google?

That would be a reasonable interpretation,  if that is the case WF showing an example of a acct URI that has a % encoded @ in the account name part would be helpful.

I was thinking that acct:[email-masked] would be passed to the .well-known endpoint.   For interoperability this needs to be clear.

Thanks
John B.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 26 May 2013 21:11:42 -0600

On 5/26/13 9:08 PM, Mike Jones wrote:
> If we go this route, there should be an example of this in the acct spec as well.
> 
> I had assumed that I would be querying for acct:[email-masked] at Google and Facebook as well - not acct:[email-masked] at Google and acct:[email-masked] at Facebook.

That's a matter for the WebFinger spec. However, I have no objections to
adding an example to the acct-uri spec, when the WebFinger usage is settled.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Mike Jones <[email-masked]>
Date: Mon, 27 May 2013 03:08:25 +0000

-- Mike

-----Original Message-----
From: John Bradley [mailto:[email-masked]] 
Sent: Sunday, May 26, 2013 7:45 PM
To: Peter Saint-Andre
Cc: Paul E. Jones; 'Richard Barnes'; [email-masked]; Mike Jones
Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec

That is helpfull.

Thanks
John B.

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 27 May 2013 04:47:22 -0400

Personally, I think the % encoding is going a bit far.  The whole idea was
that we would provide something simple the user can use.  That's not what I
call simple.

If the WF client is a "generic" client, acct:user@domain-A is going to
result in a query to domain-A.  There's nothing else to hint or suggest
otherwise.   I would not expect a generic WF client likely query
[email-masked] at Google.  And, though Mike might have this account ID
associated with his Google account, I suspect Google also has a unique
[email-masked] or [email-masked] or some ID that is unique to the
Google domain.  In fact, I do believe it is
acct:[email-masked]. ;-)  Not so friendly, but I would
assume there might be a friendlier version.

In any case, I have no objection to the text we placed in the -14 version
that allows for a client to query a different host if it has knowledge to do
so.  That does not burden the user and is no different than a browser using
a proxy or an email server using a "smart host".  Through whatever means a
client knows query domain-B for acct:user@domain-A, I'm OK... as long as it
does not complicate the user's life.

Paul

> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Sunday, May 26, 2013 11:12 PM
> To: Mike Jones
> Cc: John Bradley; Paul E. Jones; 'Richard Barnes'; [email-masked]
> > I had assumed that I would be querying for acct:[email-masked] at
> Google and Facebook as well - not acct:[email-masked] at
> Google and acct:[email-masked] at Facebook.
>

---

From: Melvin Carvalho <[email-masked]>
Date: Mon, 27 May 2013 11:53:32 +0200

On 27 May 2013 04:44, John Bradley <[email-masked]> wrote:

> That is helpfull.
>
> So if a WF client is handed two parts account  and Domain would it be
> expected to concatenate those into a acct: URI and pass acct:[email-masked]
> @google.com to the .well-known at google?
>
> That would be a reasonable interpretation,  if that is the case WF showing
> an example of a acct URI that has a % encoded @ in the account name part
> would be helpful.
>
> I was thinking that acct:[email-masked] would be passed to the
> .well-known endpoint.   For interoperability this needs to be clear.
>

Sorry if I've missed something but would it just be

https://google.com/.well-known/webfinger?resource=acct%3Acarol%40ve7tjb.com

Where the acct:[email-masked] would be part of the the encoded query string
and the @google.com would be part of the origin?

ie Is the extra @google needed if it's already in the domain part?

---

From: John Bradley <[email-masked]>
Date: Mon, 27 May 2013 09:00:23 -0400

I don't think a user is ever going to type in acct:[email-masked]  nor  do I think acct:[email-masked].

I do think they may tell the site they are on that they sign into Google as [email-masked] , We have an existence proof of this now with people using account chooser and via a menu choice pushing that info to a Relying party to do discovery on them.

The WF spec needs to be clear on what it looks up where.

One reading of the current spec is that it should look up

https://ve7jtb.com/.well-known/webfinger?resource=acct%3Acarol%40ve7tjb.com

Mike would tell you he was thinking it would be:

And perhaps the most logically consistent one one if we want acct: to uniquely identify accounts as opposed to being a string with a acct: would be:

https://google.com/.well-known/webfinger?resource=acct%3Acarol%2540ve7tjb.com%40google.com

If WF clients take acct: uri as input then openID Connect RP need to know how to normalize the input into an acct: uri if we expect any sort of interoperability.

If as Peter suggests the host to be queried is part of the acct: uri even in the case where the local account identifier contains @, that simplifies processing.

John B.

On 2013-05-27, at 5:53 AM, Melvin Carvalho <[email-masked]> wrote:

> Where the acct:[email-masked] would be part of the the encoded query string and the @google.com would be part of the origin?
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 27 May 2013 10:47:50 -0400

tl;dr: We don't need to over-think this.  Just allow for hosts to be
explicitly specified in some cases.

So, I'm trying to think through the use cases here.  (Please forgive my
naïveté w.r.t. Account Chooser.)

AFAICT, it seems that Account Chooser is using WebFinger to gather
additional information at the "add account" stage of the process.  For
example, there's the following code snippet on accountchooser.net [1]:
"""
<script type="text/javascript">
  accountchooser.CONFIG.storeAccount = {
    email: "[email-masked]",
    displayName: "Nikhil Corlett",
    photoUrl: "https://example.com/nikhil_corlett.jpg"
    providerId: "identity.example.com" };</script>
"""

If the provider offers WebFinger, then the Account Chooser code could just
work from the "email" and "providerId" fields, pulling the rest from WF.
 It could also use WF to discover other accounts that are equivalent to
this one, through the "aliases" in the JRD.

Assuming I've got the correct idea of how Account Chooser is using WF, then
in this case it makes complete sense to send the query to a different host
than the host in the resource URI.  (Although in this case, since it's
email, "mailto" seems more appropriate than "acct"):

https://identity.example.com/.well-known/webfinger?resource=mailto%3Anikhil_corlett%40yahoo.com

The question for the document is what we assume is input to a WebFinger
query.  If we assume the input is a (URI, host) as above, then there's no
ambiguity; you just use the explicit host value.  But my reading of the
examples was that there were at least a few cases, where you would just
input a URI (esp. an acct URI).  Which means that there needs to be a
default of deriving the host from the URI.

--Richard

[1] <http://accountchooser.net/developers>

On Mon, May 27, 2013 at 8:49 AM, John Bradley <[email-masked]>wrote:

> I don't think a user is ever going to type in acct:carol%40ve7jtb.com@
> google.com  nor  do I think acct:[email-masked].
>
> I do think they may tell the site they are on that they sign into Google
> as [email-masked] , We have an existence proof of this now with people
> using account chooser and via a menu choice pushing that info to a Relying
> party to do discovery on them.
>
> And perhaps the most logically consistent one one if we want acct: to
> uniquely identify accounts as opposed to being a string with a acct: would
> be:
>
>
> If WF clients take acct: uri as input then openID Connect RP need to know
> how to normalize the input into an acct: uri if we expect any sort of
> interoperability.
>
> If as Peter suggests the host to be queried is part of the acct: uri even
> in the case where the local account identifier contains @, that simplifies
> processing.
>
> John B.
>
>> expected to concatenate those into a acct: URI and pass acct:foo@
>> [email-masked] to the .well-known at google?
>>
>> That would be a reasonable interpretation,  if that is the case WF
>> showing an example of a acct URI that has a % encoded @ in the account name
>> part would be helpful.
>>
> https://google.com/.well-known/webfinger?resource=acct%3Acarol%40ve7tjb.com<https://google.com/.well-known/webfinger?resource=acct:[email-masked]>
>
> Where the acct:[email-masked] would be part of the the encoded query
> string and the @google.com would be part of the origin?
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 27 May 2013 11:33:09 -0400

So, are there any changes needed for -14?  I think what is wanted is
covered.

Presently, it says this in Section 4:

   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, unless the client receives

   instructions through some out-of-band mechanism to send the query to

   another host. If the query target does not contain a "host" portion,

   then the client MAY choose a host to which it directs the query using

   additional information it has.

I think this is pretty close, though I do wonder whether the “MAY” in the
second sentence should be there.  Rather than using a normative word like
that, perhaps just say “the client chooses a host”, since if there is no
host portion, the client has no choice: it must have some other information
to guide it.

Paul

From: Richard Barnes [mailto:[email-masked]] 
Sent: Monday, May 27, 2013 10:48 AM
To: John Bradley
Cc: Melvin Carvalho; Peter Saint-Andre; Paul E. Jones; Mike Jones; webfinger
Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger
spec

"""

"""

If the provider offers WebFinger, then the Account Chooser code could just
work from the "email" and "providerId" fields, pulling the rest from WF.  It
could also use WF to discover other accounts that are equivalent to this
one, through the "aliases" in the JRD.

https://identity.example.com/.well-known/webfinger?resource=mailto%3Anikhil_
corlett%40yahoo.com

--Richard

 

On Mon, May 27, 2013 at 8:49 AM, John Bradley <[email-masked]>
wrote:

I don't think a user is ever going to type in
acct:[email-masked]  nor  do I think
acct:[email-masked] <http://gmail.com/> .

I do think they may tell the site they are on that they sign into Google as
[email-masked] , We have an existence proof of this now with people using
account chooser and via a menu choice pushing that info to a Relying party
to do discovery on them.

https://ve7jtb.com/.well-known/webfinger?resource=acct%3Acarol%
<https://ve7jtb.com/.well-known/webfinger?resource=acct%3Acarol%25>
40ve7tjb.com

https://google.com/.well-known/webfinger?resource=acct%3Acarol%2540ve7tjb.co
m%40google.com

If as Peter suggests the host to be queried is part of the acct: uri even in
the case where the local account identifier contains @, that simplifies
processing.

John B.

 

That is helpfull.

So if a WF client is handed two parts account  and Domain would it be
expected to concatenate those into a acct: URI and pass
acct:[email-masked]@google.com <http://google.com/>  to the .well-known at
google?

I was thinking that acct:[email-masked] <mailto:[email-masked]>
would be passed to the .well-known endpoint.   For interoperability this
needs to be clear.

https://google.com/.well-known/webfinger?resource=acct%3Acarol%40ve7tjb.com
<https://google.com/.well-known/webfinger?resource=acct:[email-masked]> 

Where the acct:[email-masked] <mailto:[email-masked]>  would be part
of the the encoded query string and the @google.com <http://google.com/>
would be part of the origin?

Thanks
John B.

On 2013-05-26, at 10:07 PM, Peter Saint-Andre <[email-masked]> wrote:

>> could have used acct:[email-masked]@google.com <http://google.com/> 
<mailto:[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Mon, 27 May 2013 12:17:29 -0400

Yes given that there is not host in the URI then change "MAY choose" to  "chooses".

Your reference for acct: is out of date, it is now  Draft 4  May 1, 2013.

From the recent list discussion it remains under documented how a agent constructs an acct: uri from the inputs.

It can be argued that as WF takes a URI as input that is someone else's problem, however some guidance someplace will avoid a lot of interoperability issues down the road, given that WF servers need to somehow parse all the varying forms of identifiers to return the response.

So to see if everyone is on the same page, is this correct.

Hiven that almost no one is going to enter an acc: scheme URI directly the software will need to construct one from one or more inputs.

Scenario 1 (uncontroversial)
1 The software is given a string by the user "[email-masked]".
2 The software performs some magic pattern match to decide that it is not a URI and is in the form of an email or acct URI without a scheme.
3 The software prepends "acct:" to the string and uses that as input to WF eg "acct:[email-masked]".
4 WF takes the URI input and extracts the host portion and performs the following query.
GET /.well-known/webfinger?
            resource=acct%3Acarol%40example.com&
            rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
            HTTP/1.1
     Host: example.com

5 WF gets response all happy.

Scenario 2 (perhaps controversial)
1 The software is told that the userpart is [email-masked] and the host is google.com.
2 The software constructs a acct: uri by url encoding the userpart and appending @ followed by the host and prepending "acct:".  eg "acct:[email-masked]"
3 The software uses "acct:[email-masked]" as input to WF.
4 WF takes the URI input and extracts the host portion and performs the following query.
GET /.well-known/webfinger?
            resource=acct%3Acarol%2540example.com%40google.com&
            rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
            HTTP/1.1
     Host: google.com

5 WF gets response all happy.

Having more than 1 theory for scenario 2 will cause interop issues.
We could specify the normalization in Connect discovery, however if wee do it one way and another protocol using webfinger picks another way it will be a issue for WF servers needing to map the various identifiers to the accounts.   I would argue that WF should provide guidance on this because it is the WF server that needs to know what to expect as input.  

If everyone thinks scenario 2 was completely obvious and what they were intending to do, then 14 is good.

John B.

On 2013-05-27, at 11:33 AM, "Paul E. Jones" <[email-masked]> wrote:

> So, are there any changes needed for -14?  I think what is wanted is covered.
>  
> I think this is pretty close, though I do wonder whether the “MAY” in the second sentence should be there.  Rather than using a normative word like that, perhaps just say “the client chooses a host”, since if there is no host portion, the client has no choice: it must have some other information to guide it.
>  
> Paul
>  
> tl;dr: We don't need to over-think this.  Just allow for hosts to be explicitly specified in some cases.
>  
> So, I'm trying to think through the use cases here.  (Please forgive my naïveté w.r.t. Account Chooser.)
>  
> AFAICT, it seems that Account Chooser is using WebFinger to gather additional information at the "add account" stage of the process.  For example, there's the following code snippet on accountchooser.net [1]:
> """
> If the provider offers WebFinger, then the Account Chooser code could just work from the "email" and "providerId" fields, pulling the rest from WF.  It could also use WF to discover other accounts that are equivalent to this one, through the "aliases" in the JRD.
>  
> Assuming I've got the correct idea of how Account Chooser is using WF, then in this case it makes complete sense to send the query to a different host than the host in the resource URI.  (Although in this case, since it's email, "mailto" seems more appropriate than "acct"):
>  
> The question for the document is what we assume is input to a WebFinger query.  If we assume the input is a (URI, host) as above, then there's no ambiguity; you just use the explicit host value.  But my reading of the examples was that there were at least a few cases, where you would just input a URI (esp. an acct URI).  Which means that there needs to be a default of deriving the host from the URI.
>  
> --Richard
>  
> On Mon, May 27, 2013 at 8:49 AM, John Bradley <[email-masked]> wrote:

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 28 May 2013 12:42:26 -0400

John,

I changed “MAY choose” to “chooses” and corrected the reference to the acct
URI spec.  Those changes will appear when we publish the next revision.  We
still have DISCUSS items to get back to before I do that.

What you describe as Scenario 1 is the only way I had ever expected
WebFinger to work (and the only way I’ve seen WebFinger or Host-Meta
implemented).

The one “soft” exception might be step 4.  Generally, a client would extract
the host portion and direct the query there, just as you described.
However, folks want to be allowed the option to use the acct URI (not a
mangled version, but the ‘acct:[email-masked]’ URI) with a different host
than the host portion specifies.  If a client has some reason to believe
that’s the correct thing to do, then fine.  How a client knows to do this
I’d argue is beyond the scope of the WF spec.

Paul

From: John Bradley [mailto:[email-masked]] 
Sent: Monday, May 27, 2013 12:17 PM
To: Paul E. Jones
Cc: 'Richard Barnes'; 'John Bradley'; 'webfinger'; 'Mike Jones'; 'Peter
Saint-Andre'; 'Melvin Carvalho'
Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger
spec

Yes given that there is not host in the URI then change "MAY choose" to
"chooses".

>From the recent list discussion it remains under documented how a agent
constructs an acct: uri from the inputs.

It can be argued that as WF takes a URI as input that is someone else's
problem, however some guidance someplace will avoid a lot of
interoperability issues down the road, given that WF servers need to somehow
parse all the varying forms of identifiers to return the response.

Hiven that almost no one is going to enter an acc: scheme URI directly the
software will need to construct one from one or more inputs.

2 The software performs some magic pattern match to decide that it is not a
URI and is in the form of an email or acct URI without a scheme.

3 The software prepends "acct:" to the string and uses that as input to WF
eg "acct:[email-masked]".

4 WF takes the URI input and extracts the host portion and performs the
following query.

1 The software is told that the userpart is [email-masked] and the host
is google.com.

2 The software constructs a acct: uri by url encoding the userpart and
appending @ followed by the host and prepending "acct:".  eg
"acct:[email-masked]"

4 WF takes the URI input and extracts the host portion and performs the
following query.

We could specify the normalization in Connect discovery, however if wee do
it one way and another protocol using webfinger picks another way it will be
a issue for WF servers needing to map the various identifiers to the
accounts.   I would argue that WF should provide guidance on this because it
is the WF server that needs to know what to expect as input.  

If everyone thinks scenario 2 was completely obvious and what they were
intending to do, then 14 is good.

John B.

Paul

AFAICT, it seems that Account Chooser is using WebFinger to gather
additional information at the "add account" stage of the process.  For
example, there's the following code snippet on  <http://accountchooser.net>
accountchooser.net [1]:

"""

    email: " <mailto:[email-masked]> [email-masked]",

    photoUrl: " <https://example.com/nikhil_corlett.jpg>
https://example.com/nikhil_corlett.jpg"

    providerId: " <http://identity.example.com> identity.example.com"
};</script>

"""

 
<https://identity.example.com/.well-known/webfinger?resource=mailto%3Anikhil
_corlett%40yahoo.com>
https://identity.example.com/.well-known/webfinger?resource=mailto%3Anikhil_
corlett%40yahoo.com

--Richard

[1] < <http://accountchooser.net/developers>
http://accountchooser.net/developers>

On Mon, May 27, 2013 at 8:49 AM, John Bradley <
<mailto:[email-masked]> [email-masked]> wrote:

I don't think a user is ever going to type in acct:carol%
<http://40ve7jtb.com> 40ve7jtb.com@ <http://google.com> google.com  nor  do
I think acct:113649649235174428485@ <http://gmail.com/> gmail.com.

I do think they may tell the site they are on that they sign into Google as
<mailto:[email-masked]> [email-masked] , We have an existence proof of
this now with people using account chooser and via a menu choice pushing
that info to a Relying party to do discovery on them.

 <https://ve7jtb.com/.well-known/webfinger?resource=acct%3Acarol%25>
https://ve7jtb.com/.well-known/webfinger?resource=acct%3Acarol%
<http://40ve7tjb.com> 40ve7tjb.com

 
<https://google.com/.well-known/webfinger?resource=acct%3Acarol%40ve7tjb.com

 
<https://google.com/.well-known/webfinger?resource=acct%3Acarol%2540ve7tjb.c
o>
https://google.com/.well-known/webfinger?resource=acct%3Acarol%2540ve7tjb.co
m% <http://40google.com> 40google.com

John B.

On 2013-05-27, at 5:53 AM, Melvin Carvalho <
<mailto:[email-masked]> [email-masked]> wrote:

On 27 May 2013 04:44, John Bradley < <mailto:[email-masked]>
[email-masked]> wrote:

That is helpfull.

So if a WF client is handed two parts account  and Domain would it be
expected to concatenate those into a acct: URI and pass acct:foo@
<http://ve7jtb.com> ve7jtb.com@ <http://google.com/> google.com to the
.well-known at google?

I was thinking that  <mailto:[email-masked]> acct:[email-masked]
would be passed to the .well-known endpoint.   For interoperability this
needs to be clear.

Where the  <mailto:[email-masked]> acct:[email-masked] would be part
of the the encoded query string and the @ <http://google.com/> google.com
would be part of the origin?

Thanks
John B.

On 2013-05-26, at 10:07 PM, Peter Saint-Andre < <mailto:[email-masked]>
[email-masked]> wrote:

>> at Google or some other WF host is  <mailto:[email-masked]>
[email-masked]
>> <mailto: <mailto:[email-masked]> [email-masked]> and being allowed to
resolve that.
>> could have used acct:foo@ <http://ve7jtb.com> ve7jtb.com@
<http://google.com/> google.com
>> <mailto: <mailto:[email-masked]> [email-masked]>, but that
probably would have confused
>
> Peter
>
> --
> Peter Saint-Andre
>  <https://stpeter.im/> https://stpeter.im/
>
>

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

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 May 2013 11:10:51 -0600

:)

A: Because it messes up the order in which people normally read text.

Q: Why is top-posting so bad?

A: Top-posting.

Q: What is the most annoying behavior on email discussion lists?

On 5/27/13 7:00 AM, John Bradley wrote:
> acct:carol%40ve7jtb.com <http://40ve7jtb.com/>@google.com
> <http://google.com/>  nor  do I think
> acct:[email-masked] <http://gmail.com/>.

A user is never going to type "acct:" anything.

Depending on the service and the interface provided by the service, a
user might type "[email-masked]" as a username at a service, and
software might translate that into [email-masked] to pass
as a parameter when passing a WebFinger request to foo.com.

> I do think they may tell the site they are on that they sign into
> Google as [email-masked] <mailto:[email-masked]> , We have an
> existence proof of this now with people using account chooser and
> via a menu choice pushing that info to a Relying party to do
> discovery on them.
> 
<http://40ve7tjb.com/>
>  And perhaps the most logically consistent one one if we want acct:
> to uniquely identify accounts as opposed to being a string with a
> acct: would be:
> 
<http://40google.com>
> 
> If WF clients take acct: uri as input then openID Connect RP need
> to know how to normalize the input into an acct: uri if we expect
> any sort of interoperability.
> 
> If as Peter suggests the host to be queried is part of the acct:
> uri even in the case where the local account identifier contains @,
> that simplifies processing.

So it seems to me. Simpler is better. :-)

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 May 2013 11:14:02 -0600

On 5/28/13 10:42 AM, Paul E. Jones wrote:

> What you describe as Scenario 1 is the only way I had ever
> expected WebFinger to work (and the only way I?ve seen WebFinger or
> Host-Meta implemented).
> 
> The one ?soft? exception might be step 4.  Generally, a client
> would extract the host portion and direct the query there, just as
> you described.  However, folks want to be allowed the option to use
> the acct URI (not a mangled version, but the
> ?acct:[email-masked]? URI) with a different host than the host
> portion specifies.  If a client has some reason to believe that?s
> the correct thing to do, then fine.  How a client knows to do this
> I?d argue is beyond the scope of the WF spec.

What helps us ensure interoperability here? Are the rules for
constructing an 'acct:' URI something that a service would define in
their API documents?

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 29 May 2013 15:28:32 -0400

Peter,

> constructing an 'acct:' URI something that a service would define in

If the "acct" URI is going to be used in some way other than by observing
the domain part and issuing the query to that domain, then whatever is using
that URI would have something defined.  Whether that is published in an API
spec or not, I can't say.  But, I don't think it should be a part of the WF
spec.

Paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 May 2013 16:17:16 -0600

> spec or not, I can't say.  But, I don't think it should be a part of the WF

Hi Paul,

Sure, that makes sense.

I *think* there's still an open issue of how to handle localparts that
are of the form user@host (e.g., services that use an email address for
registration). So if I register with foo.com with my [email-masked]
address and foo.com thinks [email-masked] is the localpart of my acct
URI, do we perform the hex-encoding of the '@' character to come up with
"acct:[email-masked]"? At the leads, do we make any sort of
recommendation about this in the WF spec or do we leave it totally up to
implementations? And does it warrant a sentence in the acct-uri spec?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 29 May 2013 19:40:04 -0400

Peter,

> implementations? And does it warrant a sentence in the acct-uri spec?

If you register with foo.com using your email address, that does not
automatically mean foo.com is going to use that identifier in any way for
WebFinger.  If I have a blog where you register with [email-masked], my
server might issue a WF query to example.com to get your picture, name, or
other information for display on the blog when you post comments, for
example.

So, I suppose the question arises when a user on the Internet wants to query
information about you at your foo.com account.  The way it ought to work is
that foo.com assign an account identifier for you.  So, you might be
acct:[email-masked].  Then querying becomes quite natural.  Foo.com is not
obliged to even run a WF server, too.

Now, should foo.com decide it does not want to assign account identifiers
that people can use, yet they still want people to be able to query
information about users at the service, then it gets complicated.  I would
not dare suggest to the average user to type in
acct:[email-masked].  Rather, if foo.com wants to provide a WF
service and it uses acct:[email-masked] as the account ID, then some
system that knows and understands that would issue a query to foo.com using
the resource identifier acct:[email-masked].

Just to carry this a bit further, just imagine if someone signs up at
bar.com with their foo.com account.  Then we could have %-encoded %-encoded
stuff.  This gets really messy.  If a service wants to allow for use of WF
against the service, they should assign the user an account ID that is
different from whatever account ID that might have used to create the
account.  Or, just resign to the fact that the interface will require that
the peer know and understand that the identifiers presented will not
necessarily be foo.com identifiers.  There are cases where this might be
valid and useful, but we do not have to describe such uses in the standard.

At least that's my view.  I'd rather not make this complicated and this can
really get messy.

Paul