From paulej@packetizer.com Tue May 21 19:03:42 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6699821F9256 for ; Tue, 21 May 2013 19:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfwN68iw8OJE for ; Tue, 21 May 2013 19:03:37 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2E28021F922A for ; Tue, 21 May 2013 19:03:36 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r4M23Zk9007421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 21 May 2013 22:03:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1369188215; bh=BvtgAt5R7A/DNcgQZPZTTD5SBJE9RFnyftW5cNuY/GM=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=rfFcZfNr9Pi4FoP8XIE4UKoSddIYAhdhLQtDQxhbn7ct/HgfhVf3O0vmcOObcPPcA LrWyQfHUxKZUbCfO+PJKZZvKV/ZPLYy9qyA4RbxFWcA2dUYX7hdmcWd14O/wuXrNY9 WtvxFNCYOj46pSi3oWtHUNI/4Pe9pG9N1SRAcBRU= From: "Paul E. Jones" To: Date: Tue, 21 May 2013 22:03:40 -0400 Message-ID: <046301ce5690$95173ad0$bf45b070$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5WkHndln2th2AzS36gYGGYRsJOyA== Content-Language: en-us Subject: [webfinger] Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 02:03:42 -0000 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 bortzmeyer@nic.fr Thu May 23 01:00:10 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7ED821F93BC for ; Thu, 23 May 2013 01:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJUETOnaDtN8 for ; Thu, 23 May 2013 01:00:05 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 03BBA21F939E for ; Thu, 23 May 2013 01:00:02 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 95533280291; Thu, 23 May 2013 09:59:30 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 909512801C0; Thu, 23 May 2013 09:59:30 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:113]) by relay1.nic.fr (Postfix) with ESMTP id 8468D4C0053; Thu, 23 May 2013 09:59:00 +0200 (CEST) Date: Thu, 23 May 2013 09:59:00 +0200 From: Stephane Bortzmeyer To: "Paul E. Jones" Message-ID: <20130523075900.GA24875@nic.fr> References: <046301ce5690$95173ad0$bf45b070$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046301ce5690$95173ad0$bf45b070$@packetizer.com> X-Operating-System: Debian GNU/Linux 7.0 X-Kernel: Linux 3.2.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: webfinger@ietf.org Subject: Re: [webfinger] Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 08:00:10 -0000 On Tue, May 21, 2013 at 10:03:40PM -0400, Paul E. Jones 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 Michael.Jones@microsoft.com Thu May 23 15:40:01 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77C221F977E for ; Thu, 23 May 2013 15:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wDKKJ00moWY for ; Thu, 23 May 2013 15:39:57 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id 9D55B21F859D for ; Thu, 23 May 2013 15:29:03 -0700 (PDT) Received: from BY2FFO11FD017.protection.gbl (10.1.15.201) by BY2FFO11HUB031.protection.gbl (10.1.14.116) with Microsoft SMTP Server (TLS) id 15.0.698.0; Thu, 23 May 2013 22:27:58 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD017.mail.protection.outlook.com (10.1.14.105) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Thu, 23 May 2013 22:27:58 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0136.001; Thu, 23 May 2013 22:26:55 +0000 From: Mike Jones To: "Paul E. Jones" , "webfinger@ietf.org" Thread-Topic: [webfinger] Preparing for next revision of the WebFinger spec Thread-Index: Ac5WkHndln2th2AzS36gYGGYRsJOyABcxQIw Date: Thu, 23 May 2013 22:26:54 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436775DF4D@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <046301ce5690$95173ad0$bf45b070$@packetizer.com> In-Reply-To: <046301ce5690$95173ad0$bf45b070$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(377454002)(13464003)(52604005)(199002)(66066001)(50466002)(74876001)(53806001)(74706001)(31966008)(69226001)(81542001)(47736001)(63696002)(65816001)(55846006)(79102001)(6806003)(80022001)(56776001)(23726002)(74366001)(47446002)(74662001)(51856001)(81342001)(46406003)(46102001)(47776003)(44976003)(16406001)(54316002)(50986001)(4396001)(33656001)(74502001)(76482001)(77982001)(56816002)(47976001)(59766001)(20776003)(49866001)(54356001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB031; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 085551F5A8 Subject: Re: [webfinger] Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:40:02 -0000 Item 1 - I would back out this change or reword it because it has unintende= d consequences. I have an account named mbj@microsoft.com at Facebook. I = have one named mbj@microsoft.com at Google. It must be legal to query for = acct:mbj@microsoft.com at google.com and at facebook.com, or information ab= out those accounts could not be discovered. (I can work on specific wordin= g with you if you want to keep parts of this change, rather than just backi= ng 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: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beh= alf Of Paul E. Jones Sent: Tuesday, May 21, 2013 7:04 PM To: webfinger@ietf.org 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 th= ose, 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 chang= es, publish revised text, and then we can go back to the additional open DI= SCUSS items. ITEM 1 ------ Section 4, paragraph leading with "The host to which a WebFinger query is i= ssued is significant." I think the intent was good and guidance is right i= n general, but some expressed concern. If I recall the concern, it was tha= t local policy might conflict with these stated procedures. For example, o= ne might design an application that performs WF queries and targets a speci= fic 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 pa= ragraph is problematic, then we should consider removing it. I see this as= no different than what most applications do: they would usually direct que= ries to the specified host, but might have local policies that specify a di= fferent result. For example, my MTA would usually try to deliver mail to t= he 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 d= iscussed 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 serve= r can definitely control whether the client will ever even use HEAD by mana= ging 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 sugge= st we change this to "und", as suggested by experts on the list. I'm not s= ure what to do about the RFC 6415 discrepancy, but I would say it is an err= or 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 goo= d to go on these. Nonetheless, I want to enumerate them before I publish t= he 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 w= e can go back to the other DISCUSS items. Paul _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger From ve7jtb@ve7jtb.com Thu May 23 16:04:24 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD1321F95EF for ; Thu, 23 May 2013 16:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mD7rITE-ALdU for ; Thu, 23 May 2013 16:04:22 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id B9C4921F9345 for ; Thu, 23 May 2013 16:04:18 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id n1so2101500qcw.13 for ; Thu, 23 May 2013 16:04:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=D/Vk8hhUaIGrshUlJf6HMTehljIx2+Hfxh6pF/F9lgM=; b=P7fu3oM4B1ARY9NxQKHuk33MYgZm916aPt41e0dlj9j2rFFIn2Glojer/AaUuafaLz FpdqkJECdOo1q71gmEpQvBi2qa8R/iyz/5LKTNSLXfWNKbEldDGiaJQ1OJ6RtR4mKFoJ y8bsOmKXJ0nbj6gHIzogckBPxRcglfCrq2TmsVehdewuBGy4R90IAhHCfSZVTg3R0VqS C42s3wR+tOHRV8wW/jiY4Iiz9Jix1x3u1jqvLxIH6KlsZyNh2/fTSLwQjZyUnVER8g/d bXYuOOV+b/C1R7KPJDpB1MvUIJ4htAa1Ddq+4SH/dE76XrDdFRaL1BohfxNs3Jdkv3KM tmnw== X-Received: by 10.224.105.7 with SMTP id r7mr14006871qao.72.1369350258196; Thu, 23 May 2013 16:04:18 -0700 (PDT) Received: from [192.168.1.36] (190-20-17-66.baf.movistar.cl. [190.20.17.66]) by mx.google.com with ESMTPSA id c10sm2308602qag.2.2013.05.23.16.04.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 May 2013 16:04:16 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_F7589FE4-391E-4EAD-8402-2C95BDBA5F48"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436775DF4D@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 23 May 2013 19:04:07 -0400 Message-Id: <0E69CE2E-C995-4ED4-B1ED-D449AE852DE6@ve7jtb.com> References: <046301ce5690$95173ad0$bf45b070$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436775DF4D@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkyr70pS79lnrwBkvqwZjGNqSNczo28ql4ZdsHnW9nRZgHdrlpLQodlDsszpHy8Ye/ePlXh Cc: "Paul E. Jones" , "webfinger@ietf.org" Subject: Re: [webfinger] Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 23:04:24 -0000 --Apple-Mail=_F7589FE4-391E-4EAD-8402-2C95BDBA5F48 Content-Type: multipart/alternative; boundary="Apple-Mail=_FE9721CA-3444-441B-925E-30ED0CCB5167" --Apple-Mail=_FE9721CA-3444-441B-925E-30ED0CCB5167 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 ve7jtb@hotmail.com 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=20 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 = wrote: > Item 1 - I would back out this change or reword it because it has = unintended consequences. I have an account named mbj@microsoft.com at = Facebook. I have one named mbj@microsoft.com at Google. It must be = legal to query for acct:mbj@microsoft.com 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.) >=20 > Item 2 - We should say nothing about HEAD since HTTP already specifies = its behavior. Please delete the new text. >=20 > Item 3 - I'm fine with SHOULD. >=20 > Item 4 - We should change to the standard identifier "und". I'm also = fine with an errata being filed against RFC 6415. >=20 > Item 5 - I'm fine with these changes. >=20 > Thanks for working to move this forward. >=20 > -- Mike >=20 > -----Original Message----- > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On Behalf Of Paul E. Jones > Sent: Tuesday, May 21, 2013 7:04 PM > To: webfinger@ietf.org > Subject: [webfinger] Preparing for next revision of the WebFinger spec >=20 > Folks, >=20 > 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. >=20 > 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. >=20 > 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? >=20 > 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. >=20 > 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. >=20 > 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? >=20 > 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" >=20 > 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. >=20 > Paul >=20 >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --Apple-Mail=_FE9721CA-3444-441B-925E-30ED0CCB5167 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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 ve7jtb@hotmail.com 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 <Michael.Jones@microsoft.com> wrote:

Item 1 - I would back out this change or reword it because = it has unintended consequences.  I have an account named mbj@microsoft.com at Facebook. =  I have one named mbj@microsoft.com at Google. =  It must be legal to query for acct:mbj@microsoft.com 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: webfinger-bounces@ietf.org = [mailto:webfinger-bounces@ietf.org] On Behalf Of Paul = E. Jones
Sent: Tuesday, May 21, 2013 7:04 PM
To: webfinger@ietf.org
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
webfinger@ietf.org
https://www.i= etf.org/mailman/listinfo/webfinger
____________________________________= ___________
webfinger mailing = list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfin= ger

= --Apple-Mail=_FE9721CA-3444-441B-925E-30ED0CCB5167-- --Apple-Mail=_F7589FE4-391E-4EAD-8402-2C95BDBA5F48 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTIzMjMwNDA4WjAjBgkqhkiG9w0BCQQxFgQUodNYKH+G VvZb2ntgxqoJPnej3C4wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAIXWBlViz0orFzvehGcSpcHoQ6I4o9at6YLT7Jspd 9d8cfTx98VZu0l+ZeYfeDBLKZExTGBXuJXgXWXqmVY0bLhL5AUZyY2HAU9L9Ym+/DrY88OqMZ6kx UGL/125RQi4e+mOdbneRew5z5A03aA3NVlxsUUJMebqWlImdqqjG0fphcEJJaT6KSENMyNIYqpLu ByVmZt4UNWnrCmf0pY9wc98p2L6HD8I296qVF3uCMvfEdQwa1zFklKmy9asXm41nlUAwdbEI1PxJ K5JMNaux6BmYP1Trkbr2Vjq+fx88lI8UisEiiltHVm/XgZE9FHCNFWcsnYHe4AvW3ZnGFPrdwAAA AAAAAA== --Apple-Mail=_F7589FE4-391E-4EAD-8402-2C95BDBA5F48-- From paulej@packetizer.com Fri May 24 12:55:21 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B35821F93F4 for ; Fri, 24 May 2013 12:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKZwGllkUf0p for ; Fri, 24 May 2013 12:55:17 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id F219E21F93E1 for ; Fri, 24 May 2013 12:55:16 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r4OJtFfU008262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 May 2013 15:55:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1369425316; bh=8hiVVAv+Qw8oQeqhLb7QBsiBXUzJSFWJlSTxP9yTEUc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=KCV/d0IGwR2dT3ceyvNcKJ8/UX1tXXMTGEABbnF8XJdB1YN3rYhrqh8hGGr7u2D2A VrEfE02rI4xudDRjQ2/VK7IaaGHUsTS/WxYlq8IzxJCxXwnT48nbKc60oZs3d/LCo3 6m17lgf0mxpydLYw8D0YP1CgO7RmcV/saBxH9rrk= From: "Paul E. Jones" To: "'Richard Barnes'" Date: Fri, 24 May 2013 15:55:22 -0400 Message-ID: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5Yt+eIjJTpTj82SQmwc/Hu+zQ0Tg== Content-Language: en-us Cc: webfinger@ietf.org, 'Mike Jones' Subject: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 19:55:21 -0000 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:Michael.Jones@microsoft.com] > Sent: Thursday, May 23, 2013 6:27 PM > To: Paul E. Jones; webfinger@ietf.org > 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 mbj@microsoft.com at > Facebook. I have one named mbj@microsoft.com at Google. It must be legal > to query for acct:mbj@microsoft.com 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: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On > Behalf Of Paul E. Jones > Sent: Tuesday, May 21, 2013 7:04 PM > To: webfinger@ietf.org > 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 > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger From Michael.Jones@microsoft.com Fri May 24 14:11:44 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0F811E80F6 for ; Fri, 24 May 2013 14:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrW-6o8hh-ph for ; Fri, 24 May 2013 14:11:39 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 9F53A11E80A5 for ; Fri, 24 May 2013 14:11:39 -0700 (PDT) Received: from BL2FFO11FD025.protection.gbl (10.173.161.202) by BL2FFO11HUB032.protection.gbl (10.173.161.56) with Microsoft SMTP Server (TLS) id 15.0.698.0; Fri, 24 May 2013 21:11:35 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD025.mail.protection.outlook.com (10.173.161.104) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Fri, 24 May 2013 21:11:35 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.134]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0136.001; Fri, 24 May 2013 21:11:33 +0000 From: Mike Jones To: Richard Barnes , "Paul E. Jones" Thread-Topic: FW: [webfinger] Preparing for next revision of the WebFinger spec Thread-Index: AQHOWLp0Tek/z9Ur6ESGhkDZYBPUYpkU094g Date: Fri, 24 May 2013 21:11:32 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367793529TK5EX14MBXC285r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(129404003)(51914003)(24454002)(51704005)(52604005)(377454002)(189002)(199002)(13464003)(74366001)(31966008)(56776001)(47446002)(80022001)(76482001)(59766001)(74502001)(20776003)(47976001)(53806001)(44976003)(54316002)(74662001)(74876001)(69226001)(46102001)(65816001)(51856001)(50986001)(54356001)(4396001)(71186001)(56816002)(49866001)(63696002)(15202345002)(16406001)(47736001)(55846006)(81342001)(16601075002)(74706001)(16236675002)(512954002)(77982001)(79102001)(81542001)(33656001)(6806003)(66066001)(16940595002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB032; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 085634EFF4 Cc: "webfinger@ietf.org" Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 21:11:44 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367793529TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable s/has been configured/knows/ and I'm good with it. ("Configured" sounds st= atic, whereas "knows" is more dynamic, which is often likely to be the actu= al case.) I'd also suggest this change for generality: s/local policy/additional info= rmation that it has/ - again, more dynamic in nature. -- Mike From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Friday, May 24, 2013 1:08 PM To: Paul E. Jones Cc: Mike Jones; webfinger@ietf.org Subject: Re: FW: [webfinger] Preparing for next revision of the WebFinger s= pec 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 directi= on 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 hos= t to which the WebFinger query is issued MUST be the same as the "host" por= tion of the query target, unless the client has been configured through som= e out-of-band mechanism to send the query to another host. If the query tar= get 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 > wrote: 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:Michael.Jones@microsoft.com] > Sent: Thursday, May 23, 2013 6:27 PM > To: Paul E. Jones; webfinger@ietf.org > Subject: RE: [webfinger] Preparing for next revision of the WebFinger spe= c > > Item 1 - I would back out this change or reword it because it has > unintended consequences. I have an account named mbj@microsoft.com at > Facebook. I have one named mbj@microsoft.com a= t Google. It must be legal > to query for acct:mbj@microsoft.com at g= oogle.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, rathe= r > than just backing it out.) > > Item 2 - We should say nothing about HEAD since HTTP already specifies it= s > 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 fin= e > 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: webfinger-bounces@ietf.org [mail= to:webfinger-bounces@ietf.org] On > Behalf Of Paul E. Jones > Sent: Tuesday, May 21, 2013 7:04 PM > To: webfinger@ietf.org > 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 th= e > 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 thos= e > 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 righ= t > 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 woul= d > 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 eve= r > 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 w= e > 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 agre= e > 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 adher= e > 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 b= e > 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 o= f > 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 > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --_000_4E1F6AAD24975D4BA5B168042967394367793529TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

s/has been configu= red/knows/ and I’m good with it.  (“Configured” sounds static,= whereas “knows” is more dynamic, which is often likely to be t= he actual case.)

 <= /p>

I’d also suggest th= is change for generality: s/local policy/= additional information that it has/ – again, more dy= namic in nature.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         -- Mike

 <= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Friday, May 24, 2013 1:08 PM
To: Paul E. Jones
Cc: Mike Jones; webfinger@ietf.org
Subject: Re: FW: [webfinger] Preparing for next revision of the WebF= inger spec

 

Hey Paul,

 

Thanks for the heads-up on this.

 

I would argue that this is like HTTP.  If I han= d 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 conne= ct to that host.  So what we want is a carve-out from the MUST to cover cases where there's explicit direction to go elsewh= ere.  Proposed text:

 

"""

The host to which a WebFinger query is issued is sig= nificant.  If the query target contains a "host" portion (Se= ction 3.2.2 of RFC 3986), then the host to which the WebFinger query is iss= ued MUST be the same as the "host" portion of the query target, unless the client has been configured through some out-of-ba= nd mechanism to send the query to another host. If the query target does no= t 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 con= figured through some out-of-band mechanism to send the query to another hos= t"

 

Hope this helps,

--Richard

 

 

 

On Fri, May 24, 2013 at 3:55 PM, Paul E. Jones <<= a href=3D"mailto:paulej@packetizer.com" target=3D"_blank">paulej@packetizer= .com> wrote:

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 gui= dance
would be best.

Paul

> -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Thursday, May 23, 2013 6:27 PM
> To: Paul E. Jones; webfinger@iet= f.org
> 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 mbj@microsoft.com at
> Facebook.  I have one named = mbj@microsoft.com at Google.  It must be legal
> to query for acct:mbj@micr= osoft.com 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, ra= ther
> 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: webfinger-bounces@= ietf.org [mailto:webfinge= r-bounces@ietf.org] On
> Behalf Of Paul E. Jones
> Sent: Tuesday, May 21, 2013 7:04 PM
> To: webfinger@ietf.org
> Subject: [webfinger] Preparing for next revision of the WebFinger spec=
>
> Folks,
>
> It has been a while since we updated the WebFinger spec.  I was o= ut 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 dr= aft.
> I took noted as folks made comments.  I'd like to run through eac= h of
> those and suggest a text change.  If we can get agreement, I'll m= ake those
> changes, publish revised text, and then we can go back to the addition= al
> 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 gui= dance is right
> in general, but some expressed concern.  If I recall the concern,= it was
> that local policy might conflict with these stated procedures.  F= or
> example, one might design an application that performs WF queries and<= br> > targets a specific host, regardless of the "host" part. &nbs= p;I have no strong
> opinion on this one, but if there are use cases where not following th= e
> guidance of this paragraph is problematic, then we should consider
> removing it.  I see this as no different than what most applicati= ons do:
> they would usually direct queries to the specified host, but might hav= e
> 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 u= se 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 w= as 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 al= l HTTP
> stuff, not something we need to go into in the WF spec, IMO.  I s= uggest we
> remove that paragraph.
>
> ITEM 3
> ------
> Section 4.4.1, we require "subject" to be present, but it wa= s raised on
> the list that this is not in line with RFC 6415 and the XRD spec. &nbs= p;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 spec= ify
> "und"
> for this, including the RFC referenced right in the first paragraph. &= nbsp;RFC
> 6415 used "default", thus we did here.  To not perpetua= te 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.  W= e should
> submit and errata against RFC 6415 on the grounds that it failed to ad= here
> to the relevant RFC.  Thoughts?
>
> ITEM 5
> ------
> Few changes in 8.2 that were fully hashed on the list, so I think we'r= e
> good to go on these.  Nonetheless, I want to enumerate them befor= e 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 auth= orized by the
> person
>       whose information is being shared" changed t= o "WebFinger MUST NOT be
>       used to provide any personal data unless publishi= ng 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 outsid= e of
> the DISCUSS items.  If we can close on these 5, I'll update the d= raft and
> we can go back to the other DISCUSS items.
>
> Paul
>
>
> _______________________________________________
> webfinger mailing list
> webfinger@ietf.org
> https://www.ietf.org/mailman/listinfo/webfinger

 

--_000_4E1F6AAD24975D4BA5B168042967394367793529TK5EX14MBXC285r_-- From rlb@ipv.sx Fri May 24 13:07:56 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED92A21F9050 for ; Fri, 24 May 2013 13:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.063 X-Spam-Level: X-Spam-Status: No, score=-1.063 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydOb7WHYGvHW for ; Fri, 24 May 2013 13:07:51 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6B221F8EEC for ; Fri, 24 May 2013 13:07:51 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id va2so5906776obc.41 for ; Fri, 24 May 2013 13:07:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Gp3/2MHnfUIlAPVrsDjVfqce+rsEMwN2mhn6V76grRs=; b=edzGIB8SnuH3rQhkht3r3O9sZ+wPd5rxMI015lXibBoy5Vg9f646yNqfrwES7ZwcLy v0KBHejb6GOSj1EZtWBGagb6mfJTMXFL25fnJgop3t6vL4u3Ugezko7LFII5a47dlv8a ZBUJOzSbJBGAyvOOlkxm6dPasPS5ZwFdoFwlESwgD/DNkijWO1p4LPRO8MLZ6sM33S7o YfZWV751Ld5Jds8KL1f4XqKhxoP4Fe2Isw7KzDExO6frv6ak1IkZUNQLIMw08Vf/Jbhr LmkjjiPRf3tXQT5IB5SnVzHKHW6/X8MGw6mdNg7WmGNAVLmqNcfsTHjVe/MowlQWqdXm J1Tw== MIME-Version: 1.0 X-Received: by 10.182.105.67 with SMTP id gk3mr13018751obb.7.1369426071114; Fri, 24 May 2013 13:07:51 -0700 (PDT) Received: by 10.60.102.146 with HTTP; Fri, 24 May 2013 13:07:51 -0700 (PDT) X-Originating-IP: [128.89.254.202] In-Reply-To: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> Date: Fri, 24 May 2013 16:07:51 -0400 Message-ID: From: Richard Barnes To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8ff2509083ec2104dd7c5a29 X-Gm-Message-State: ALoCoQlNw2G5L5m0+7YYbc0d9F/BVm6JdZhPboEsie+BupPkCRv4gFvYzEmlTUCjV93RhpqOecOL X-Mailman-Approved-At: Sun, 26 May 2013 12:17:02 -0700 Cc: "webfinger@ietf.org" , Mike Jones Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 20:07:56 -0000 --e89a8ff2509083ec2104dd7c5a29 Content-Type: text/plain; charset=ISO-8859-1 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 wrote: > 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:Michael.Jones@microsoft.com] > > Sent: Thursday, May 23, 2013 6:27 PM > > To: Paul E. Jones; webfinger@ietf.org > > 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 mbj@microsoft.com at > > Facebook. I have one named mbj@microsoft.com at Google. It must be > legal > > to query for acct:mbj@microsoft.com 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: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On > > Behalf Of Paul E. Jones > > Sent: Tuesday, May 21, 2013 7:04 PM > > To: webfinger@ietf.org > > 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 > > webfinger@ietf.org > > https://www.ietf.org/mailman/listinfo/webfinger > > --e89a8ff2509083ec2104dd7c5a29 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hey Paul,

Thanks for the heads-up on th= is.

I would argue that this is like HTTP. =A0If I = hand you an HTTP URI to look up, by default the host you connect to is the = one in the URI. =A0But if you're UA is configured to use a proxy, you c= onnect to that host. =A0So what we want is a carve-out from the MUST to cov= er cases where there's explicit direction to go elsewhere. =A0Proposed = text:

"""
The host to which a W= ebFinger query is issued is significant. =A0If the query target contains a = "host" portion (Section 3.2.2 of RFC 3986), then the host to whic= h the WebFinger query is issued MUST be the same as the "host" po= rtion of the query target, unless the client has been configured through so= me out-of-band mechanism to send the query to another host. If the query ta= rget does not contain a "host" portion, then the client MAY choos= e a host to which it directs the query based on local policy.
"""

In other words: &quo= t;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 <paulej@packetizer.com> wrote:
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? =A0Mike has offered to re-word it, but I think your guidan= ce
would be best.

Paul

> -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Thursday, May 23, 2013 6:27 PM
> To: Paul E. Jones; webfinger@iet= f.org
> 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. =A0I have an account named mbj@microsoft.com at
> Facebook. =A0I have one named mbj= @microsoft.com at Google. =A0It must be legal
> to query for acct:mbj@micr= osoft.com at google.com= and at facebook.com<= /a>, or
> information about those accounts could not be discovered. =A0(I can wo= rk on
> specific wording with you if you want to keep parts of this change, ra= ther
> than just backing it out.)
>
> Item 2 - We should say nothing about HEAD since HTTP already specifies= its
> behavior. =A0Please delete the new text.
>
> Item 3 - I'm fine with SHOULD.
>
> Item 4 - We should change to the standard identifier "und". = =A0I'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.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike >
> -----Original Message-----
> From: webfinger-bounces@= ietf.org [mailto:webfinge= r-bounces@ietf.org] On
> Behalf Of Paul E. Jones
> Sent: Tuesday, May 21, 2013 7:04 PM
> To: webfinger@ietf.org
> Subject: [webfinger] Preparing for next revision of the WebFinger spec=
>
> Folks,
>
> It has been a while since we updated the WebFinger spec. =A0I 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. =A0However, before we get bac= k to
> those, I'd like to address issues raised with the current publishe= d draft.
> I took noted as folks made comments. =A0I'd like to run through ea= ch of
> those and suggest a text change. =A0If we can get agreement, I'll = make those
> changes, publish revised text, and then we can go back to the addition= al
> open DISCUSS items.
>
> ITEM 1
> ------
> Section 4, paragraph leading with "The host to which a WebFinger = query is
> issued is significant." =A0I think the intent was good and guidan= ce is right
> in general, but some expressed concern. =A0If I recall the concern, it= was
> that local policy might conflict with these stated procedures. =A0For<= br> > example, one might design an application that performs WF queries and<= br> > targets a specific host, regardless of the "host" part. =A0I= have no strong
> opinion on this one, but if there are use cases where not following th= e
> guidance of this paragraph is problematic, then we should consider
> removing it. =A0I see this as no different than what most applications= do:
> they would usually direct queries to the specified host, but might hav= e
> local policies that specify a different result. =A0For example, my MTA= would
> usually try to deliver mail to the specified host, but I can specify a=
> "smart host" that receives all mail. =A0Likewise, I can use = a proxy with my
> browser for HTTP requests. =A0What does the group want? =A0Keep it, re= move it,
> or does someone have specific changes they would like to see?
>
> ITEM 2
> ------
> Last paragraph of Section 4.2 introduces the HEAD method. =A0That was = never
> discussed before and, the more I think about it, the less I think we > should say anything. =A0The HTTP spec already provides guidance on thi= s
> issue. =A0HEAD is required for general purpose web servers, but not > otherwise. =A0The server can definitely control whether the client wil= l ever
> even use HEAD by managing the cache headers properly. =A0This is all H= TTP
> stuff, not something we need to go into in the WF spec, IMO. =A0I sugg= est we
> remove that paragraph.
>
> ITEM 3
> ------
> Section 4.4.1, we require "subject" to be present, but it wa= s raised on
> the list that this is not in line with RFC 6415 and the XRD spec. =A0I= 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 spec= ify
> "und"
> for this, including the RFC referenced right in the first paragraph. = =A0RFC
> 6415 used "default", thus we did here. =A0To not perpetuate = an error, I
> suggest we change this to "und", as suggested by experts on = the list. =A0I'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. =A0We s= hould
> submit and errata against RFC 6415 on the grounds that it failed to ad= here
> to the relevant RFC. =A0Thoughts?
>
> ITEM 5
> ------
> Few changes in 8.2 that were fully hashed on the list, so I think we&#= 39;re
> good to go on these. =A0Nonetheless, I want to enumerate them before I=
> publish the changes. =A0Those changes are:
> =A0 =A0 o Removal of the last sentence of the first paragraph of 8.2 > =A0 =A0 o Also in 8.2, changing "WebFinger MUST NOT be used to pr= ovide any
> =A0 =A0 =A0 personal data to any party unless explicitly authorized by= the
> person
> =A0 =A0 =A0 whose information is being shared" changed to "W= ebFinger MUST NOT be
> =A0 =A0 =A0 used to provide any personal data unless publishing that d= ata via
> =A0 =A0 =A0 WebFinger by the relevant service was explicitly authorize= d by the
> =A0 =A0 =A0 person whose information is being shared"
>
> That's it for now, unless folks are aware of other items raised ou= tside of
> the DISCUSS items. =A0If 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
> webfinger@ietf.org
> https://www.ietf.org/mailman/listinfo/webfinger


--e89a8ff2509083ec2104dd7c5a29-- From rlb@ipv.sx Sat May 25 13:28:38 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350C521F8C98 for ; Sat, 25 May 2013 13:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19lz3owoCHLX for ; Sat, 25 May 2013 13:28:32 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id A610321F8B64 for ; Sat, 25 May 2013 13:28:32 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id o17so7428535oag.41 for ; Sat, 25 May 2013 13:28:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=jasFzS4i3++o3ANBZm50/f8AYSjmW0aa43GqOEisVWM=; b=PNXRkkdFdgqLJVEpxLGbewXuRjoYM81QVt2zD0rDSFftNzXA1EnFs99klnY8wYpEA9 oMHUctQDa/yaBkkKW+1TKhAJH8bBgyNWmZbnB9005qPctFbKcHHBUxu6BAyx96wvss8d Dt7Ao4C438NbUo7E9lXvd64Bp710niaXP4OPmlNZiI4HWBrtKr2kzNgQQSeWVbd38zjN IkhLh1+2df1CjVuEapDdQGTglZc0T2NmwL4ZWiw209LgVxy5cC6qqRL+7kh1tcqE4HWu wB8a05MPPjdSCSADEqiCLTY9t0fS3b47asvbV3+XvlXV06K0MpgqeF264jKjzXwz5ssI cG6g== MIME-Version: 1.0 X-Received: by 10.182.105.67 with SMTP id gk3mr15184248obb.7.1369513711994; Sat, 25 May 2013 13:28:31 -0700 (PDT) Received: by 10.60.102.146 with HTTP; Sat, 25 May 2013 13:28:31 -0700 (PDT) X-Originating-IP: [108.18.40.68] In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Sat, 25 May 2013 16:28:31 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=e89a8ff2509051994004dd90c2d6 X-Gm-Message-State: ALoCoQn4lAcFIf8R1L4wUqXGyhgULqZMr084anrJoLLOdHRdMDvAXNKxv52iHR5fQI0iKtUwqClx X-Mailman-Approved-At: Sun, 26 May 2013 12:17:02 -0700 Cc: "Paul E. Jones" , "webfinger@ietf.org" Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 20:28:38 -0000 --e89a8ff2509051994004dd90c2d6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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=92m good with it. (=93Configured=94 = sounds > static, whereas =93knows=94 is more dynamic, which is often likely to be = the > actual case.)**** > > ** ** > > I=92d also suggest this change for generality: s/local policy/additional > information that it has/ =96 again, more dynamic in nature.**** > > ** ** > > -- Mike**= * > * > > ** ** > > *From:* Richard Barnes [mailto:rlb@ipv.sx 'rlb@ipv.sx');>] > *Sent:* Friday, May 24, 2013 1:08 PM > *To:* Paul E. Jones > *Cc:* Mike Jones; webfinger@ietf.org 'webfinger@ietf.org');> > *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 wha= t > we want is a carve-out from the MUST to cover cases where there's explici= t > 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 > wrote:**** > > 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 guidan= ce > would be best. > > Paul > > > -----Original Message----- > > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > > Sent: Thursday, May 23, 2013 6:27 PM > > To: Paul E. Jones; webfinger@ietf.org > > 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 mbj@microsoft.com at > > Facebook. I have one named mbj@microsoft.com at Google. It must be > legal > > to query for acct:mbj@microsoft.com 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: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On > > Behalf Of Paul E. Jones > > Sent: Tuesday, May 21, 2013 7:04 PM > > To: > --e89a8ff2509051994004dd90c2d6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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". =A0
On Friday, May 24, 2013, Mike Jones wrote:

s/has been configu= red/knows/ and I=92m good with it.=A0 (=93Configured=94 sounds static, whereas =93kno= ws=94 is more dynamic, which is often likely to be the actual case.)=

=A0<= /p>

I=92d also suggest this c= hange for generality: s/local policy/additional information that it has/ =96 again, more dynami= c in nature.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Friday, May 24, 2013 1:08 PM
To: Paul E. Jones
Cc: Mike Jones; webfinger@ietf.org
Subject: Re: FW: [webfinger] Preparing for next revision of the WebF= inger spec

=A0

Hey Paul,

=A0

Thanks for the heads-up on this.

=A0

I would argue that this is like HTTP. =A0If I hand you an HTTP URI to lo= ok up, by default the host you connect to is the one in the URI. =A0But if = you're UA is configured to use a proxy, you connect to that host. =A0So= what we want is a carve-out from the MUST to cover cases where there's explicit direction to go el= sewhere. =A0Proposed text:

=A0

"""

The host to which a WebFinger query is issued is significant. =A0If 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-ba= nd mechanism to send the query to another host. If the query target does no= t contain a "host" portion, then the client MAY choose a host to = which it directs the query based on local policy.

"""

=A0

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

=A0

Hope this helps,

--Richard

=A0

=A0

=A0

On Fri, May 24, 2013 at 3:55 PM, Paul E. Jones <paulej@packetizer.= com> wrote:

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? =A0Mike has offered to re-word it, but I think your guidan= ce
would be best.

Paul

> -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Thursday, May 23, 2013 6:27 PM
> To: Paul E. Jones; webfinger@ietf.org
> 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. =A0I have an account named mbj@microsoft.com at
> Facebook. =A0I have one named mbj@microsoft.com at Google. =A0I= t must be legal
> to query for acct:mbj@microsoft.com at google.com and at facebook.com, or
> information about those accounts could not be discovered. =A0(I can wo= rk on
> specific wording with you if you want to keep parts of this change, ra= ther
> than just backing it out.)
>
> Item 2 - We should say nothing about HEAD since HTTP already specifies= its
> behavior. =A0Please delete the new text.
>
> Item 3 - I'm fine with SHOULD.
>
> Item 4 - We should change to the standard identifier "und". = =A0I'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.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike >
> -----Original Message-----
> From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@i= etf.org] On
> Behalf Of Paul E. Jones
> Sent: Tuesday, May 21, 2013 7:04 PM
> To:

--e89a8ff2509051994004dd90c2d6-- From paulej@packetizer.com Sun May 26 16:18:27 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D10C21F9485 for ; Sun, 26 May 2013 16:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPNloDJpK27b for ; Sun, 26 May 2013 16:18:22 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE8221F9473 for ; Sun, 26 May 2013 16:18:22 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r4QNICRi004600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 26 May 2013 19:18:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1369610294; bh=rb43gQOEqMxTjwIe/pAMpyWO9WjE/1DYrOWLcPxFMS4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=rh9tgSTvDtqh33J3v6ZpTnrOl2uVV01D93513kzdxZqpCQCCNxN7Iscdgt5ehY3VX 9TFxKU57fqf3oIzSJfQeSpDh8wCyrzmy0IBDDnXBG18l6AS9jd34KSrkizOayYnHNM xGmd54c76KvhsLUKvfNEE/BlejAtCZqYd8pTMJWA= From: "Paul E. Jones" To: "'Richard Barnes'" , "'Mike Jones'" References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: Date: Sun, 26 May 2013 19:18:14 -0400 Message-ID: <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017D_01CE5A45.C5DB2600" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIGFCMJveTXWbzKSo6DGHvDY3YlOgJh9aLuAegQv70CYfVhSJhzRfIw Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 23:18:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_017D_01CE5A45.C5DB2600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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:rlb@ipv.sx] Sent: Saturday, May 25, 2013 4:29 PM To: Mike Jones Cc: Paul E. Jones; webfinger@ietf.org Subject: Re: FW: [webfinger] Preparing for next revision of the WebFinger spec 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:rlb@ipv.sx ] Sent: Friday, May 24, 2013 1:08 PM To: Paul E. Jones Cc: Mike Jones; webfinger@ietf.org 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 wrote: 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:Michael.Jones@microsoft.com] > Sent: Thursday, May 23, 2013 6:27 PM > To: Paul E. Jones; webfinger@ietf.org > 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 mbj@microsoft.com at > Facebook. I have one named mbj@microsoft.com at Google. It must be legal > to query for acct:mbj@microsoft.com 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: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On > Behalf Of Paul E. Jones > Sent: Tuesday, May 21, 2013 7:04 PM > To: ------=_NextPart_000_017D_01CE5A45.C5DB2600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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:rlb@ipv.sx]
Sent: Saturday, May 25, = 2013 4:29 PM
To: Mike Jones
Cc: Paul E. Jones; = webfinger@ietf.org
Subject: Re: FW: [webfinger] Preparing for = next revision of the WebFinger spec

 

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.

 

           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   -- Mike

 

From:= = Richard Barnes [mailto:rlb@ipv.sx]
Sent: Friday, May 24, 2013 = 1:08 PM
To: Paul E. Jones
Cc: Mike Jones; webfinger@ietf.org
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:

 

&quo= t;""

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 <paulej@packetizer.com> = wrote:

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:Michael.Jones@microsof= t.com]
> Sent: Thursday, May 23, 2013 6:27 PM
> To: Paul = E. Jones; webfinger@ietf.org
> = 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 mbj@microsoft.com = at
> Facebook.  I have one named mbj@microsoft.com at Google. =  It must be legal
> to query for acct:mbj@microsoft.com 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: webfinger-bounces@ietf.org= [mailto:webfinger-bounces@ietf.= org] On
> Behalf Of Paul E. Jones
> Sent: Tuesday, May = 21, 2013 7:04 PM
> To: =

------=_NextPart_000_017D_01CE5A45.C5DB2600-- From paulej@packetizer.com Sun May 26 16:37:23 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E901C21F9195 for ; Sun, 26 May 2013 16:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwMrUMPVWD-o for ; Sun, 26 May 2013 16:37:19 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 56A2621F911B for ; Sun, 26 May 2013 16:37:19 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r4QNbIke005514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 26 May 2013 19:37:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1369611438; bh=jcy80lIrwkwPlRrfTyeNSFJ560mLZYSoIxs/l5Fnddk=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=mmw01NtmcN/hrDC6YmU7sISGPx/KlbV7+emCGRF75XG2yrj/d9C38iKGYnzX+Amt5 vkZXdEbk+O0VQjscZRN2UVq0OTVPdPV0ISuGeplcoWRlpoeBp0as9kgbKSnrUvuTm7 OVEh0lBojb9spf8GtHx3fU7CyBvFL+Yehdz31Wy4= From: "Paul E. Jones" To: References: <20130526233521.6482.87690.idtracker@ietfa.amsl.com> In-Reply-To: <20130526233521.6482.87690.idtracker@ietfa.amsl.com> Date: Sun, 26 May 2013 19:37:20 -0400 Message-ID: <018f01ce5a69$f728df80$e57a9e80$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHC++vW+M8zkMN5O4w3IfkLltOmgpku3AfA Content-Language: en-us Subject: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-14.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 23:37:24 -0000 FYI > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: Sunday, May 26, 2013 7:35 PM > To: i-d-announce@ietf.org > Cc: apps-discuss@ietf.org > Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-14.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group Working > Group of the IETF. > > Title : WebFinger > Author(s) : Paul E. Jones > Gonzalo Salgueiro > Joseph Smarr > Filename : draft-ietf-appsawg-webfinger-14.txt > Pages : 23 > Date : 2013-05-26 > > 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 IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-14 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-14 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From ve7jtb@ve7jtb.com Sun May 26 18:38:02 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6BEB21F95EA for ; Sun, 26 May 2013 18:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDAmSX4xTSOs for ; Sun, 26 May 2013 18:38:01 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7B021F95E7 for ; Sun, 26 May 2013 18:38:01 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 16so17324837iea.31 for ; Sun, 26 May 2013 18:38:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=GtU1Ivmfb9Tw6Y2x5EFBeP2vrhN27gU+mpyuawRtT78=; b=NDiLaoTTEHEmbC5z57i7rg37PLbL4v/yY7U+39LIv+BTPqpNHuQMZ9fy7iiLleNgVg EPdf3OK/Ah3CWNvWVxiqLyWNiLpNazZugEyGege0qU/uTGzHbNTieMCA0Qgi89/FXhqH GKeoSviob823D3QmIjE8f3mYzUMcsBc1kRQz1wxPzZg+ha0C25PsWjcx9xrB/dFaRSc4 G1sk7bOrAUK6HZVSNCzwlE/FrmBsaaLEm1bw1aiAyxLhJUKbKkcI8auYzbyvIkT1lQ5j MKWdBtw/foppsq0UlVHTFROhZ3YINKcgp0Y1L0WlTpsO3Mtveph6vujC8YA0Fz3meIC5 wPMw== X-Received: by 10.50.72.48 with SMTP id a16mr3719576igv.90.1369618680736; Sun, 26 May 2013 18:38:00 -0700 (PDT) Received: from [192.168.1.36] (190-20-31-243.baf.movistar.cl. [190.20.31.243]) by mx.google.com with ESMTPSA id d7sm11180306igx.5.2013.05.26.18.37.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 May 2013 18:37:59 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A30448AD-4F75-4ACF-AF38-0B0EDAACFDDA"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> Date: Sun, 26 May 2013 21:37:33 -0400 Message-Id: References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQnyM8Ht3cmwhg/SCrTE3Y1ZyNIV1fPYL8fv0gcEICXJvAKT/1Xv+YcG4rIu82VeRGPvDgP9 Cc: 'Richard Barnes' , webfinger@ietf.org, 'Mike Jones' Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 01:38:02 -0000 --Apple-Mail=_A30448AD-4F75-4ACF-AF38-0B0EDAACFDDA Content-Type: multipart/alternative; boundary="Apple-Mail=_20E1C0EE-731C-496C-AFC4-E9E19124D965" --Apple-Mail=_20E1C0EE-731C-496C-AFC4-E9E19124D965 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Fine as long as a WF client being told explicitly the account identifier = at Google or some other WF host is foo@ve7jtb.com 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:foo@ve7jtb.com@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" = wrote: > Guys, > =20 > OK, I think we=92re converging > =20 > I used =93unless the client receives instructions through some = out-of-band mechanism to send the query to another host=94 and =93=85to = which it directs the query using additional information it has.=94 > =20 > Paul > =20 > From: Richard Barnes [mailto:rlb@ipv.sx]=20 > Sent: Saturday, May 25, 2013 4:29 PM > To: Mike Jones > Cc: Paul E. Jones; webfinger@ietf.org > Subject: Re: FW: [webfinger] Preparing for next revision of the = WebFinger spec > =20 > You know, Mike, software hates to be anthropomorphized ;) > =20 > So I'm ok with changing words, but might prefer something like "has = external information" to "knows". =20 >=20 > On Friday, May 24, 2013, Mike Jones wrote: > s/has been configured/knows/ and I=92m good with it. (=93Configured=94 = sounds static, whereas =93knows=94 is more dynamic, which is often = likely to be the actual case.) > =20 > I=92d also suggest this change for generality: s/local = policy/additional information that it has/ =96 again, more dynamic in = nature. > =20 > -- = Mike > =20 > From: Richard Barnes [mailto:rlb@ipv.sx]=20 > Sent: Friday, May 24, 2013 1:08 PM > To: Paul E. Jones > Cc: Mike Jones; webfinger@ietf.org > Subject: Re: FW: [webfinger] Preparing for next revision of the = WebFinger spec > =20 >=20 > Hey Paul, >=20 > =20 >=20 > Thanks for the heads-up on this. >=20 > =20 >=20 > 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: >=20 > =20 >=20 > """ >=20 > 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. >=20 > """ >=20 > =20 >=20 > In other words: "unless the client has been configured through some = out-of-band mechanism to send the query to another host" >=20 > =20 >=20 > Hope this helps, >=20 > --Richard >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On Fri, May 24, 2013 at 3:55 PM, Paul E. Jones = wrote: >=20 > Richard, >=20 > I think it may have been you who was most interested in Item 1 (see = the > reference to Item 1 down below). >=20 > 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. >=20 > Paul >=20 > > -----Original Message----- > > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > > Sent: Thursday, May 23, 2013 6:27 PM > > To: Paul E. Jones; webfinger@ietf.org > > 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 mbj@microsoft.com = at > > Facebook. I have one named mbj@microsoft.com at Google. It must be = legal > > to query for acct:mbj@microsoft.com 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: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On > > Behalf Of Paul E. Jones > > Sent: Tuesday, May 21, 2013 7:04 PM > > To: >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --Apple-Mail=_20E1C0EE-731C-496C-AFC4-E9E19124D965 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Fine as long as a WF client = being told explicitly the account identifier at Google or some other WF = host is foo@ve7jtb.com 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:foo@ve7jtb.com@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" <paulej@packetizer.com> = wrote:

 
OK, I think we=92re = converging
 
I used =93unless the client receives = instructions through some out-of-band mechanism to send the query to = another host=94 and =93=85to which it directs the query using additional = information it has.=94
 
Paul
 
From: Richard Barnes = [mailto:rlb@ipv.sx] 
Sent: Saturday, May 25, 2013 4:29 = PM
To: Mike = Jones
Cc: Paul= E. Jones; webfinger@ietf.org
Subject: Re: FW: [webfinger] = Preparing for next revision of the WebFinger = spec
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=92m = good with it.  (=93Configured=94 sounds static, whereas =93knows=94 = is more dynamic, which is often likely to be the actual = case.)
 
I=92d also suggest this change = for generality: s/local policy/ =96 = again, more dynamic in nature.
 

Hey = Paul,

 

On Fri, May 24, 2013 at 3:55 = PM, Paul E. Jones < webfinger@ietf.org
> 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 mbj@microsoft.com at
> Facebook. =  I have one named mbj@microsoft.com at Google.  It must be = legal
> to query for acct:mbj@microsoft.com at  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: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On
> Behalf Of Paul E. Jones
> Sent: Tuesday, May 21, 2013 = 7:04 PM
> = To:

____________________= ___________________________
webfinger mailing list
webfinger@ietf.org
https://www.i= etf.org/mailman/listinfo/webfinger

= --Apple-Mail=_20E1C0EE-731C-496C-AFC4-E9E19124D965-- --Apple-Mail=_A30448AD-4F75-4ACF-AF38-0B0EDAACFDDA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTI3MDEzNzM0WjAjBgkqhkiG9w0BCQQxFgQUKTUKoya/ unTQoPf2Ou9GBYmZ6QUwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAI7nxMT8+CflKftv6sOrCHbFzht/6bcOKPNMIyZ1R +enGqVAm94fFpwlbd3SBCg6Xrbp0h123E3nJeVXmg5XI4LYCXeVOvcVUP+QPoMxnkYiO37mdCO8G 25tr049GtAO62uznN08UrwXfId/WKdUATQ0B4tdlqx0aMWAtl+UViMjdu3mqqM3ZCmN6/ibII5z0 9BKx1bxX0FIkyTfolzL32X+k8Ps2+Wt2GQbI0evb7vLnIPjIEDse4GecxJqkxA5tC1L4C5NqbU2N DybuKB+nHE+vCo/ErrfSlMKcQF50OiGA9fPWqnNO00+u1iHQDYzm1m/nBWte9OttbvMKG9p77QAA AAAAAA== --Apple-Mail=_A30448AD-4F75-4ACF-AF38-0B0EDAACFDDA-- From stpeter@stpeter.im Sun May 26 19:08:01 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC12921F9600 for ; Sun, 26 May 2013 19:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USebGNY2bovd for ; Sun, 26 May 2013 19:07:55 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AD88821F9601 for ; Sun, 26 May 2013 19:07:47 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EB7624113B; Sun, 26 May 2013 20:20:26 -0600 (MDT) Message-ID: <51A2BFF3.2000208@stpeter.im> Date: Sun, 26 May 2013 20:07:47 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Bradley References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Richard Barnes' , "Paul E. Jones" , 'Mike Jones' , webfinger@ietf.org Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 02:08:01 -0000 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 foo@ve7jtb.com > 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:foo@ve7jtb.com@google.com > , but that probably would have confused > people in itself. Standard percent-encoding rules from RFC 3986 allow this: acct:foo%40ve7jtb.com@google.com Peter -- Peter Saint-Andre https://stpeter.im/ From ve7jtb@ve7jtb.com Sun May 26 19:45:28 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6AF21F92B7 for ; Sun, 26 May 2013 19:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COsQg3kVQrXG for ; Sun, 26 May 2013 19:45:27 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id DCA3A21F91A0 for ; Sun, 26 May 2013 19:45:26 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id a14so17143972iee.41 for ; Sun, 26 May 2013 19:45:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=sLG2G/y6XeTzt7mkNlNBxXM3wce0XgjMKuNER6d2SFY=; b=TGeM0j4K74bRrX/Op+p/xyG9CFMop4pTdW+B260TwMtA9wtEeHgta5sZkM4EGgrsSQ O0aQBAnk6L/p2A6PHNkjPrOQlIBGPdH76YsoblB2fOKEDqi6abADSY/cda7x6R3bWaRJ eBYhwzl2AGDALfAQbDMNWhL7gDUAnnaoHPQ2y3sHMHXGZlXHFXxczEizYG7/bHBlI3rW yVs+EvlKZCqIEISKpxnSXmh7YxkC0j3pH6wkW3TkLbsDjee+sTqLgmbCpLKkGAAEfPsr ytjYGnvLcTxdpzXVEhNPKk6SSw9eYUKivsleT/IBtSUe0EawSj0TMCfWr9sB+9QwMok0 IaOw== X-Received: by 10.50.153.42 with SMTP id vd10mr4020362igb.43.1369622726284; Sun, 26 May 2013 19:45:26 -0700 (PDT) Received: from [192.168.1.36] (190-20-31-243.baf.movistar.cl. [190.20.31.243]) by mx.google.com with ESMTPSA id 9sm11407683igy.7.2013.05.26.19.45.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 May 2013 19:45:24 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_70515225-1F93-496E-BC67-54B89EC0AD7C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <51A2BFF3.2000208@stpeter.im> Date: Sun, 26 May 2013 22:44:48 -0400 Message-Id: <804F2B2A-D2C5-4ADB-BFD3-4F10C0BA6587@ve7jtb.com> References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> <51A2BFF3.2000208@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlLWWVe46vojYBDo+Vz4LHhtujmFV+MNvQIGKDmZP1eEbKI1+m30sKa4j8VS610VBNcPiZt Cc: 'Richard Barnes' , "Paul E. Jones" , 'Mike Jones' , webfinger@ietf.org Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 02:45:28 -0000 --Apple-Mail=_70515225-1F93-496E-BC67-54B89EC0AD7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 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@ve7jtb.com@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:foo@ve7jtb.com would be passed to the = .well-known endpoint. For interoperability this needs to be clear. Thanks John B. On 2013-05-26, at 10:07 PM, Peter Saint-Andre = wrote: > 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 foo@ve7jtb.com >> and being allowed to resolve that. >>=20 >> 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. >>=20 >> We don't have any good way to represent that with acct URI. I guess = we >> could have used acct:foo@ve7jtb.com@google.com >> , but that probably would have confused >> people in itself. >=20 > Standard percent-encoding rules from RFC 3986 allow this: >=20 > acct:foo%40ve7jtb.com@google.com >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 --Apple-Mail=_70515225-1F93-496E-BC67-54B89EC0AD7C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTI3MDI0NDQ4WjAjBgkqhkiG9w0BCQQxFgQUCBd5ePLc CgH00o2nNwzvVXiEJYYwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAMxH45JQ+OfyzQUAUXOSu6mmE8tsHFF+KtR83BgFn SOTSva92HAH1fVmrXqFqflXaWYP9Zhj9L4DSWjPl4cpVWOzAWFfTe8j1U+6x+8jgRoQuL+/CZeXy NdzeRGYZlyusBm5rCgeGIam18BTjOfU7fEeWgXcmnhH8qomllDiZiKMM+WO5vW46g7QN/pOFHG85 RvGjoOYO880P+fhMAzXDaMdYY/js7M5pwCBObxnLHR272hPCVqJ8VMvgC38nT73CHsclyUAwTwfv GvV3GlVVcrUgFREGDbJTVzUoAgd7+HJGtq2eoyHVWRW5a+HqJceZdZboDf4psvLY/WVyzWZ8AQAA AAAAAA== --Apple-Mail=_70515225-1F93-496E-BC67-54B89EC0AD7C-- From stpeter@stpeter.im Sun May 26 20:13:57 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628B221F848C for ; Sun, 26 May 2013 20:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY7XDNqYKAsJ for ; Sun, 26 May 2013 20:13:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0900721F8206 for ; Sun, 26 May 2013 20:12:23 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5FAD74119A; Sun, 26 May 2013 21:24:21 -0600 (MDT) Message-ID: <51A2CEEE.3010405@stpeter.im> Date: Sun, 26 May 2013 21:11:42 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Mike Jones References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> <51A2BFF3.2000208@stpeter.im> <804F2B2A-D2C5-4ADB-BFD3-4F10C0BA6587@ve7jtb.com> <4E1F6AAD24975D4BA5B1680429673943677A7265@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943677A7265@TK5EX14MBXC285.redmond.corp.microsoft.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: John Bradley , "Paul E. Jones" , 'Richard Barnes' , "webfinger@ietf.org" Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 03:13:58 -0000 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:mbj@microsoft.com at Google and Facebook as well - not acct:mbj%40microsoft.com@google.com at Google and acct:mbj%40microsoft.com@facebook.com 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 Michael.Jones@microsoft.com Sun May 26 20:14:41 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C1D21F8D94 for ; Sun, 26 May 2013 20:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSuj42dmMKdK for ; Sun, 26 May 2013 20:14:35 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id B784821F8D31 for ; Sun, 26 May 2013 20:14:35 -0700 (PDT) Received: from BL2FFO11FD026.protection.gbl (10.173.161.203) by BL2FFO11HUB020.protection.gbl (10.173.160.112) with Microsoft SMTP Server (TLS) id 15.0.698.0; Mon, 27 May 2013 03:08:47 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD026.mail.protection.outlook.com (10.173.161.105) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Mon, 27 May 2013 03:08:47 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.134]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0136.001; Mon, 27 May 2013 03:08:26 +0000 From: Mike Jones To: John Bradley , Peter Saint-Andre Thread-Topic: [webfinger] FW: Preparing for next revision of the WebFinger spec Thread-Index: AQHOWnrbUitbfsm4g0Wri8pxSmuQvpkYSQGAgAAKVwCAAAYaoA== Date: Mon, 27 May 2013 03:08:25 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943677A7265@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> <51A2BFF3.2000208@stpeter.im> <804F2B2A-D2C5-4ADB-BFD3-4F10C0BA6587@ve7jtb.com> In-Reply-To: <804F2B2A-D2C5-4ADB-BFD3-4F10C0BA6587@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(13464003)(199002)(377454002)(479174002)(24454002)(377424003)(51704005)(59766001)(55846006)(54316002)(46406003)(6806003)(69226001)(81342001)(47736001)(77982001)(50466002)(23726002)(16406001)(4396001)(33656001)(56816002)(81542001)(54356001)(49866001)(79102001)(66066001)(74366001)(74502001)(74706001)(47446002)(46102001)(44976003)(50986001)(31966008)(47776003)(51856001)(74662001)(74876001)(53806001)(20776003)(76482001)(80022001)(65816001)(47976001)(56776001)(63696002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB020; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 085956473E Cc: 'Richard Barnes' , "Paul E. Jones" , "webfinger@ietf.org" Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 03:14:41 -0000 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:mbj@microsoft.com at Google= and Facebook as well - not acct:mbj%40microsoft.com@google.com at Google a= nd acct:mbj%40microsoft.com@facebook.com at Facebook. -- Mike -----Original Message----- From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 Sent: Sunday, May 26, 2013 7:45 PM To: Peter Saint-Andre Cc: Paul E. Jones; 'Richard Barnes'; webfinger@ietf.org; Mike Jones Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger s= pec That is helpfull. So if a WF client is handed two parts account and Domain would it be expec= ted to concatenate those into a acct: URI and pass acct:foo@ve7jtb.com@goog= le.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 wo= uld be helpful. I was thinking that acct:foo@ve7jtb.com would be passed to the .well-known = endpoint. For interoperability this needs to be clear. Thanks John B. On 2013-05-26, at 10:07 PM, Peter Saint-Andre wrote: > 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 foo@ve7jtb.com >> and being allowed to resolve that. >>=20 >> 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. >>=20 >> We don't have any good way to represent that with acct URI. I guess we >> could have used acct:foo@ve7jtb.com@google.com >> , but that probably would have confused >> people in itself. >=20 > Standard percent-encoding rules from RFC 3986 allow this: >=20 > acct:foo%40ve7jtb.com@google.com >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 From paulej@packetizer.com Mon May 27 01:47:26 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C4021F8FAF for ; Mon, 27 May 2013 01:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u46hAQLiQTte for ; Mon, 27 May 2013 01:47:22 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 53B4921F8F5D for ; Mon, 27 May 2013 01:47:22 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r4R8lKRZ031501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 May 2013 04:47:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1369644441; bh=LehjWSDPGkLLvvit+4rta4ri4mufqtF/49JBK2XnGNE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=D/rAPZfv1AT7HuybY8lhhOhWZMSRblf3yyzpKhowyDL0275C7NskGfG6p9jMvaj+M pZZLDYWhlUS2IHQC+F9AXF6zy7v9ckajOIyQPzcWMrmadY49zuJfMoURJ2f7/0T2F6 FpP2iI7xxjyklQKLvA9uSvRu1k7Yv6J3zY/XPkWY= From: "Paul E. Jones" To: "'Peter Saint-Andre'" , "'Mike Jones'" References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> <51A2BFF3.2000208@stpeter.im> <804F2B2A-D2C5-4ADB-BFD3-4F10C0BA6587@ve7jtb.com> <4E1F6AAD24975D4BA5B1680429673943677A7265@TK5EX14MBXC285.redmond.corp.microsoft.com> <51A2CEEE.3010405@stpeter.im> In-Reply-To: <51A2CEEE.3010405@stpeter.im> Date: Mon, 27 May 2013 04:47:22 -0400 Message-ID: <023d01ce5ab6$ced730c0$6c859240$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIGFCMJveTXWbzKSo6DGHvDY3YlOgJh9aLuAegQv70CYfVhSAIOSle3AsggLckA/gss1wEdCMq5ATu+jaEBj2AV7Zgl+uFw Content-Language: en-us Cc: 'John Bradley' , 'Richard Barnes' , webfinger@ietf.org Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 08:47:27 -0000 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 mbj@microsoft.com at Google. And, though Mike might have this account ID associated with his Google account, I suspect Google also has a unique user@gmail.com or user@plus.google.com or some ID that is unique to the Google domain. In fact, I do believe it is acct:113649649235174428485@gmail.com. ;-) 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 > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: Sunday, May 26, 2013 11:12 PM > To: Mike Jones > Cc: John Bradley; Paul E. Jones; 'Richard Barnes'; webfinger@ietf.org > Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger > spec > > 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:mbj@microsoft.com at > Google and Facebook as well - not acct:mbj%40microsoft.com@google.com at > Google and acct:mbj%40microsoft.com@facebook.com 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 melvincarvalho@gmail.com Mon May 27 02:53:38 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3312121F8E12 for ; Mon, 27 May 2013 02:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1eo+8sx-nFb for ; Mon, 27 May 2013 02:53:34 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id AF97821F8CA5 for ; Mon, 27 May 2013 02:53:33 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id w10so6596827lbi.9 for ; Mon, 27 May 2013 02:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cWbR8ahWWXITGitG7Jx3uK12yz1T/eFjU3TxLDsVQkw=; b=W5DkS8UfnWftKzAzf5uleN9ROG0YVZGJ5Vxto6kMjJB4QruPAGHXxGzBOEgzd5Zmdu 2IZJheXKIgetV1Vy/Rp+Asnslkr5uzo0zuusxcIMhtcYXRVeuihi829aocd/dW3xgrPG yfh89uRQ/a9By42JMS2pv7o/RoX6D0brjSFfGngnSobCVpTNHgBMJ12wCFw7L5grXRzk PS2tM9S/8z7nNhZ94cjbPFDlICoH8ZdyM+M38TfUpggu6pYR41ZKYA0tMgI08fMqbGa2 r+qj9p7Cls+xLvPZbmMooOpoXtvaati82TvPGmi2DDPRFXOh77bW0nG2Y7BjcSpIbgXE 23oQ== MIME-Version: 1.0 X-Received: by 10.112.131.129 with SMTP id om1mr13144616lbb.45.1369648412433; Mon, 27 May 2013 02:53:32 -0700 (PDT) Received: by 10.112.20.231 with HTTP; Mon, 27 May 2013 02:53:32 -0700 (PDT) In-Reply-To: <804F2B2A-D2C5-4ADB-BFD3-4F10C0BA6587@ve7jtb.com> References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> <51A2BFF3.2000208@stpeter.im> <804F2B2A-D2C5-4ADB-BFD3-4F10C0BA6587@ve7jtb.com> Date: Mon, 27 May 2013 11:53:32 +0200 Message-ID: From: Melvin Carvalho To: John Bradley Content-Type: multipart/alternative; boundary=047d7b33da6e17237e04ddb01f2b Cc: Richard Barnes , "Paul E. Jones" , Mike Jones , Peter Saint-Andre , webfinger Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 09:53:38 -0000 --047d7b33da6e17237e04ddb01f2b Content-Type: text/plain; charset=ISO-8859-1 On 27 May 2013 04:44, John Bradley 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@ve7jtb.com > @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:foo@ve7jtb.com 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:foo@ve7jtb.com 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? > > Thanks > John B. > > > On 2013-05-26, at 10:07 PM, Peter Saint-Andre wrote: > > > 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 foo@ve7jtb.com > >> 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:foo@ve7jtb.com@google.com > >> , but that probably would have confused > >> people in itself. > > > > Standard percent-encoding rules from RFC 3986 allow this: > > > > acct:foo%40ve7jtb.com@google.com > > > > Peter > > > > -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --047d7b33da6e17237e04ddb01f2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 27 May 2013 04:44, John Bradley <ve7jtb@ve7jtb.com> wrote:
That is helpfull.

So if a WF client is handed two parts account =A0and Domain would it be exp= ected to concatenate those into a acct: URI and pass acct:foo@ve7jtb.com@google.com to the .well-k= nown at google?

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

I was thinking that acct:foo@ve7jt= b.com would be passed to the .well-known endpoint. =A0 For interoperabi= lity this needs to be clear.

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

Where the acct:foo@ve7jtb.com 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 do= main part?
=A0

Thanks
John B.


On 2013-05-26, at 10:07 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

> On 5/26/13 7:37 PM, John Bradley wrote:
>> Fine as long as a WF client being told explicitly the account iden= tifier
>> at Google or some other WF host is foo@ve7jtb.com
>> <mailto:foo@ve7jtb.com>= ; and being allowed to resolve that.
>>
>> The notion that the domain part of an email address is always the<= br> >> authoritative server is wrong. =A0 As Mike points out many sites i= nclude
>> an @domain as part of the account name.
>>
>> We don't have any good way to represent that with acct URI. = =A0 I guess we
>> could have used acct:foo@ve7jtb.com@google.com
>> <mailto:ve7jtb.com@goo= gle.com>, but that probably would have confused
>> people in itself.
>
> Standard percent-encoding rules from RFC 3986 allow this:
>
> acct:foo%40ve7= jtb.com@google.com
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/<= /a>
>
>


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--047d7b33da6e17237e04ddb01f2b-- From ve7jtb@ve7jtb.com Mon May 27 06:00:57 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D2221F90FD for ; Mon, 27 May 2013 06:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjqO7ft4HO+H for ; Mon, 27 May 2013 06:00:56 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id F29E421F900C for ; Mon, 27 May 2013 06:00:55 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x12so18093326ief.40 for ; Mon, 27 May 2013 06:00:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to:x-mailer:x-gm-message-state; bh=l4HlcK+85qXfe1qsMgyFsxz318cR5skuxiKRWwQkeVY=; b=dipH9H5X9+f2pOMHpVsQZpuIIRuNBiEr5jFbkjNWSvwf2kRaOcQ7Mi7kyYx1YLLKiJ /loekNswI5J+m9JGv8GR5Rd6gApF39BDuNYvBjeEEu0+XZuoHso7oxAio6ejjsGoPICp tClowtYYIJRYD4Stt9hIgtBC7Y1gNKSDROKidK7dPqs3wfG7sQVbh59KtXmHWgHpV/pS G9YVrax98/SMTlBbY0GY8sudTN1SSch5v9M+In9FjYPYikYdxyCWpc0m2s7FkAJHJ2Sb nYn53Y4Wo2dhitEGFr8zF4rvuHGcRs0Bykxo0feWZ10SIyUbdFPMj//rsmvk8yXNUKWK IZ0g== X-Received: by 10.50.132.9 with SMTP id oq9mr4706248igb.40.1369659655338; Mon, 27 May 2013 06:00:55 -0700 (PDT) Received: from [192.168.1.36] (190-20-31-243.baf.movistar.cl. [190.20.31.243]) by mx.google.com with ESMTPSA id w8sm12954755igl.9.2013.05.27.06.00.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 May 2013 06:00:53 -0700 (PDT) From: John Bradley Content-Type: multipart/signed; boundary="Apple-Mail=_D273F40F-D1EF-4413-BD07-9C44E997DB45"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <1886C1FF-8693-4114-AAE1-55B0F99E89C9@ve7jtb.com> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Date: Mon, 27 May 2013 09:00:23 -0400 References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> <51A2BFF3.2000208@stpeter.im> <804F2B2A-D2C5-4ADB-BFD3-4F10C0BA6587@ve7jtb.com> To: webfinger In-Reply-To: X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQmVYaZfy1bFnc0pIN4KsZdtJH1wMhzTgJqNHeVs9FMQJrj3jekoub7tQOOO+6nfSN74WIjB Subject: Re: [webfinger] Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 13:00:57 -0000 --Apple-Mail=_D273F40F-D1EF-4413-BD07-9C44E997DB45 Content-Type: multipart/alternative; boundary="Apple-Mail=_F5C249A0-95D8-4F1E-8393-4FF6CBEDE275" --Apple-Mail=_F5C249A0-95D8-4F1E-8393-4FF6CBEDE275 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I don't think a user is ever going to type in = acct:carol%40ve7jtb.com@google.com nor do I think = acct:113649649235174428485@gmail.com. I do think they may tell the site they are on that they sign into Google = as carol@ve7jtb.com , 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=3Dacct%3Acarol%40ve7tjb.= com Mike would tell you he was thinking it would be: = https://google.com/.well-known/webfinger?resource=3Dacct%3Acarol%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: = https://google.com/.well-known/webfinger?resource=3Dacct%3Acarol%2540ve7tj= b.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 = wrote: >=20 >=20 >=20 > On 27 May 2013 04:44, John Bradley wrote: > That is helpfull. >=20 > 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@ve7jtb.com@google.com to the .well-known at google? >=20 > 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. >=20 > I was thinking that acct:foo@ve7jtb.com would be passed to the = .well-known endpoint. For interoperability this needs to be clear. >=20 > Sorry if I've missed something but would it just be >=20 > = https://google.com/.well-known/webfinger?resource=3Dacct%3Acarol%40ve7tjb.= com >=20 > Where the acct:foo@ve7jtb.com would be part of the the encoded query = string and the @google.com would be part of the origin? >=20 > ie Is the extra @google needed if it's already in the domain part? > =20 >=20 > Thanks > John B. >=20 >=20 > On 2013-05-26, at 10:07 PM, Peter Saint-Andre = wrote: >=20 > > 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 foo@ve7jtb.com > >> 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:foo@ve7jtb.com@google.com > >> , but that probably would have = confused > >> people in itself. > > > > Standard percent-encoding rules from RFC 3986 allow this: > > > > acct:foo%40ve7jtb.com@google.com > > > > Peter > > > > -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > >=20 >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 >=20 --Apple-Mail=_F5C249A0-95D8-4F1E-8393-4FF6CBEDE275 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = don't think a user is ever going to type in acct:carol%40ve7jtb.com@google.com  nor  do I = think acct:113649649235174428485@gmail.com.

I do think = they may tell the site they are on that they sign into Google as carol@ve7jtb.com , 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=3Dacct%3Acarol%40ve7tjb.com

Mike would = tell you he was thinking it would be:

https://google.com/.well-known/webfinger?resource=3Dacct%3Aca= rol%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:

https://google.com/.well-known/webfinger?resource=3Dacct%3Ac= arol%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 <melvincarvalho@gmail.com> = wrote:




On 27 May 2013 04:44, John Bradley <ve7jtb@ve7jtb.com> 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@ve7jtb.com@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:foo@ve7jtb.com 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

Where the acct:foo@ve7jtb.com 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?
 

Thanks
John B.


On 2013-05-26, at 10:07 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

> 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 foo@ve7jtb.com
>> <mailto:foo@ve7jtb.com> 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:foo@ve7jtb.com@google.com
>> <mailto:ve7jtb.com@google.com>, but = that probably would have confused
>> people in itself.
>
> Standard percent-encoding rules from RFC 3986 allow this:
>
> acct:foo%40ve7jtb.com= @google.com
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger



= --Apple-Mail=_F5C249A0-95D8-4F1E-8393-4FF6CBEDE275-- --Apple-Mail=_D273F40F-D1EF-4413-BD07-9C44E997DB45 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTI3MTMwMDI0WjAjBgkqhkiG9w0BCQQxFgQU7lcKH8MN D0x7KyUhe4QUbJyeSMowgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAFheSRxWHT8CuU6/iaCCl3cNfyfzPe7wYtTy+VCI4 dXEnMVrcAyoY1wm1EZHhKoA+ZgMg1LYq67gZhzFQZUxzqEikLw9I+8RWjO2xQrGbfabaHnN4ArbX HrzXKJaGYttzpDMlmVHccCH1KaRBgbHqti8nCaSEYOABE7o7wx5xQE9vsb5EY0sEScUZVBHSt+uZ pKvfVU1v8F+VBjA1uHYjG/gaFaqJ+xWpToiXtSaDCGs2fmK8jVjQ3Cf3Jlo3JItPOKfU0C+CKq6a GatVK/42ZxYr95eKlI83Zjx26jvuehhYqRdkJU8PEa6lxZJ5/NDWY+ojZeVYkc3Mct+CVaqtLgAA AAAAAA== --Apple-Mail=_D273F40F-D1EF-4413-BD07-9C44E997DB45-- From rlb@ipv.sx Mon May 27 07:47:55 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B4B21F938E for ; Mon, 27 May 2013 07:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE0uT-g6cWww for ; Mon, 27 May 2013 07:47:51 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF7321F8CEC for ; Mon, 27 May 2013 07:47:51 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id v19so614959obq.7 for ; Mon, 27 May 2013 07:47:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=jGAgAo4zby8K7UJWfxpBiXdFsdh2UEzKbIIMSvVTwg0=; b=VeMHaos+AaSU2z5gnAJht54PYpvEUmF/PJqkQfDunx5L+sW8m0wbW9wdqmdyUbLrvT P76MHvY5+UAk+6zkKw/b7dNFER/fvHj1kNcx+VA7yiLn0YY+iVTvdfcMG+s2AE2T+Dq6 nW0Eo2n+l5rwhskQZULWh2Iwn2M6kFOJUkCkMk/enui089DvzzybHtrsgILFtlk2K45N +Wbd+vk+JA2Vrr4ekEQsXxUsfSC2J+OBEFwsuOwaeJO+eEfNmV6lrDpOOoE5cHphuhV2 eY7xfd68X+kklLBq0Zm9bNuPU+aECtlmmSZVIN44r8nS8pLPXjz47MfVqUjcymZpBLQQ 86Nw== MIME-Version: 1.0 X-Received: by 10.60.136.234 with SMTP id qd10mr18850002oeb.15.1369666070851; Mon, 27 May 2013 07:47:50 -0700 (PDT) Received: by 10.60.102.146 with HTTP; Mon, 27 May 2013 07:47:50 -0700 (PDT) X-Originating-IP: [128.89.254.179] In-Reply-To: <4400A888-77BD-415D-96FB-7B59E1ED9598@ve7jtb.com> References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> <51A2BFF3.2000208@stpeter.im> <804F2B2A-D2C5-4ADB-BFD3-4F10C0BA6587@ve7jtb.com> <4400A888-77BD-415D-96FB-7B59E1ED9598@ve7jtb.com> Date: Mon, 27 May 2013 10:47:50 -0400 Message-ID: From: Richard Barnes To: John Bradley Content-Type: multipart/alternative; boundary=047d7b33c9829d439b04ddb43b7c X-Gm-Message-State: ALoCoQk4as2lrE943JKT+YzVGQXQBcOBo0p3cCGX05OpTa4+bH3dMCMucei+cJXkPwIGMQZ610oR Cc: "Paul E. Jones" , Mike Jones , Peter Saint-Andre , Melvin Carvalho , webfinger Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 14:47:55 -0000 --047d7b33c9829d439b04ddb43b7c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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=EFvet=E9 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"): https://identity.example.com/.well-known/webfinger?resource=3Dmailto%3Anikh= il_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] On Mon, May 27, 2013 at 8:49 AM, John Bradley wr= ote: > I don't think a user is ever going to type in acct:carol%40ve7jtb.com@ > google.com nor do I think acct:113649649235174428485@gmail.com. > > I do think they may tell the site they are on that they sign into Google > as carol@ve7jtb.com , We have an existence proof of this now with people > using account chooser and via a menu choice pushing that info to a Relyin= g > 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=3Dacct%3Acarol% > 40ve7tjb.com > > Mike would tell you he was thinking it would be: > > https://google.com/.well-known/webfinger?resource=3Dacct%3Acarol%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: woul= d > be: > > > https://google.com/.well-known/webfinger?resource=3Dacct%3Acarol%2540ve7t= jb.co > m%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 simplifie= s > processing. > > John B. > > On 2013-05-27, at 5:53 AM, Melvin Carvalho > wrote: > > > > > On 27 May 2013 04:44, John Bradley 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@ >> ve7jtb.com@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 n= ame >> part would be helpful. >> >> I was thinking that acct:foo@ve7jtb.com 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=3Dacct%3Acarol%40ve7tjb= .com > > Where the acct:foo@ve7jtb.com 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? > > >> >> Thanks >> John B. >> >> >> On 2013-05-26, at 10:07 PM, Peter Saint-Andre wrote= : >> >> > 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 foo@ve7jtb.com >> >> 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 includ= e >> >> 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:foo@ve7jtb.com@google.com >> >> , but that probably would have confused >> >> people in itself. >> > >> > Standard percent-encoding rules from RFC 3986 allow this: >> > >> > acct:foo%40ve7jtb.com@google.com >> > >> > Peter >> > >> > -- >> > Peter Saint-Andre >> > https://stpeter.im/ >> > >> > >> >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >> >> > > --047d7b33c9829d439b04ddb43b7c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
tl;dr: We don't need to over-think this. =A0Just = allow for hosts to be explicitly specified in some cases.

So, I'm trying to think through the use cases here. =A0(Please forgi= ve my na=EFvet=E9 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 p= rocess. =A0For example, there's the following code snippet on accountchooser.net [1]:
"""
<script type=3D"text/javascr= ipt">
=A0 accountchooser.CONFIG.storeAccount =3D {
<= div>=A0 =A0 email: "nikhil= _corlett@yahoo.com",
=A0 =A0 displayName: "Nikhil Corlett",
=A0 =A0 providerId: "<= a href=3D"http://identity.example.com">identity.example.com" };<= ;/script>
"""

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

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


The question for the document is what we assume is inpu= t to a WebFinger query. =A0If we assume the input is a (URI, host) as above= , then there's no ambiguity; you just use the explicit host value. =A0B= ut my reading of the examples was that there were at least a few cases, whe= re you would just input a URI (esp. an acct URI). =A0Which 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 <jbradley@pingidenti= ty.com> wrote:
I don't think a user is ever going = to type in acct:carol%40v= e7jtb.com@google.com =A0nor =A0do I think=A0acct:113649649235174428485@gmail.com.

I do think they may tell the site they are on that they sign= into Google as carol= @ve7jtb.com , 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 shoul= d look up

https://ve7jtb.com/.well-kn= own/webfinger?resource=3Dacct%3Acarol%40ve7tjb.com

Mike would = tell you he was thinking it would be:

<= /div>
https://go= ogle.com/.well-known/webfinger?resource=3Dacct%3Acarol%40ve7tjb.com

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

http= s://google.com/.well-known/webfinger?resource=3Dacct%3Acarol%2540ve7tjb.co<= /a>m%40google.com

If WF clien= ts take acct: uri as input then openID Connect RP need to know how to norma= lize 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.<= /div>

John B.

On 2013-05-27, at 5:53 AM, Melvin Carvalho <= ;melvincarval= ho@gmail.com> wrote:




On 27 May 2013 04:44, John Bradley <= ve7jtb@ve7jtb.com> wrote:
That is helpfull.

So if a WF client is handed two parts account =A0and Domain would it be exp= ected to concatenate those into a acct: URI and pass acct:foo@ve7jtb.com@google.com to the .well-known at google?

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

I was thinking that acct:foo@ve7jtb.com would be passed to the .well-known endpoint. = =A0 For interoperability this needs to be clear.

<= /div>
Sorry if I've missed something but would it just be

Where = the acct:foo@ve= 7jtb.com would be part of the the encoded query string and the @google.com would be part of t= he origin?

ie Is the extra @google needed if it's already in the do= main part?
=A0

Thanks
John B.


On 2013-05-26, at 10:07 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

> On 5/26/13 7:37 PM, John Bradley wrote:
>> Fine as long as a WF client being told explicitly the account iden= tifier
>> at Google or some other WF host is foo@ve7jtb.com
>> <mailto:foo= @ve7jtb.com> and being allowed to resolve that.
>>
>> The notion that the domain part of an email address is always the<= br> >> authoritative server is wrong. =A0 As Mike points out many sites i= nclude
>> an @domain as part of the account name.
>>
>> We don't have any good way to represent that with acct URI. = =A0 I guess we
>> could have used acct:foo@ve7jtb.com@goog= le.com
>> <mailto:ve7jtb.com@google.com>, but that probably would have confused >> people in itself.
>
> Standard percent-encoding rules from RFC 3986 allow this:
>
> acct:foo%40ve7jtb.com@google.com
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/<= /a>
>
>


_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger




--047d7b33c9829d439b04ddb43b7c-- From paulej@packetizer.com Mon May 27 08:33:13 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F4C21F9350 for ; Mon, 27 May 2013 08:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xK+t5Vqj4mVz for ; Mon, 27 May 2013 08:33:09 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2264021F9473 for ; Mon, 27 May 2013 08:33:09 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r4RFX7ep020279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 May 2013 11:33:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1369668787; bh=4YSytepmACrKV/UnuGkEWepatMZlXzvPXUepGEJKc6E=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=HMTOQ7GNKTQeMnWMH5nvfoz5Yqp0EivIWkUHwYa+olJqrc4cEuqmX3vj4xxZ/KjNK bPV9rKsYToZpCndmC66Gz2qdjVr1MjZYFDILwx+xqQWV/5Ao1iuK4FNlEEJqi3pChx Qurxx1fBPx2zG+s+yyZjcghWpJZ0Lxd9pDp0WZ40= From: "Paul E. Jones" To: "'Richard Barnes'" , "'John Bradley'" References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> <51A2BFF3.2000208@stpeter.im> <804F2B2A-D2C5-4ADB-BFD3-4F10C0BA6587@ve7jtb.com> <4400A888-77BD-415D-96FB-7B59E1ED9598@ve7jtb.com> In-Reply-To: Date: Mon, 27 May 2013 11:33:09 -0400 Message-ID: <02a701ce5aef$7e6c8d90$7b45a8b0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A8_01CE5ACD.F75CE960" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIGFCMJveTXWbzKSo6DGHvDY3YlOgJh9aLuAegQv70CYfVhSAIOSle3AsggLckA/gss1wEdCMq5AgcQ+QQBO6irjgI32FX5mBD1WqA= Content-Language: en-us Cc: 'webfinger' , 'Mike Jones' , 'Peter Saint-Andre' , 'Melvin Carvalho' Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 15:33:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02A8_01CE5ACD.F75CE960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So, are there any changes needed for -14? I think what is wanted is covered. =20 Presently, it says this in Section 4: 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 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. =20 I think this is pretty close, though I do wonder whether the =93MAY=94 = in the second sentence should be there. Rather than using a normative word = like that, perhaps just say =93the client chooses a host=94, since if there = is no host portion, the client has no choice: it must have some other = information to guide it. =20 Paul =20 From: Richard Barnes [mailto:rlb@ipv.sx]=20 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 =20 tl;dr: We don't need to over-think this. Just allow for hosts to be explicitly specified in some cases. =20 So, I'm trying to think through the use cases here. (Please forgive my na=EFvet=E9 w.r.t. Account Chooser.) =20 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]: """ """ =20 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. =20 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"): =20 https://identity.example.com/.well-known/webfinger?resource=3Dmailto%3Ani= khil_ corlett%40yahoo.com =20 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. =20 --Richard =20 [1] =20 =20 On Mon, May 27, 2013 at 8:49 AM, John Bradley = wrote: I don't think a user is ever going to type in acct:carol%40ve7jtb.com@google.com nor do I think acct:113649649235174428485@gmail.com . =20 I do think they may tell the site they are on that they sign into Google = as carol@ve7jtb.com , 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. =20 The WF spec needs to be clear on what it looks up where. =20 One reading of the current spec is that it should look up =20 https://ve7jtb.com/.well-known/webfinger?resource=3Dacct%3Acarol% 40ve7tjb.com =20 Mike would tell you he was thinking it would be: =20 https://google.com/.well-known/webfinger?resource=3Dacct%3Acarol%40ve7tjb= .com =20 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: =20 https://google.com/.well-known/webfinger?resource=3Dacct%3Acarol%2540ve7t= jb.co m%40google.com =20 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. =20 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. =20 John B. =20 On 2013-05-27, at 5:53 AM, Melvin Carvalho = wrote: =20 =20 On 27 May 2013 04:44, John Bradley 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@ve7jtb.com@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:foo@ve7jtb.com would be passed to the .well-known endpoint. For interoperability this needs to be clear. =20 Sorry if I've missed something but would it just be https://google.com/.well-known/webfinger?resource=3Dacct%3Acarol%40ve7tjb= .com =20 Where the acct:foo@ve7jtb.com 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? =20 Thanks John B. On 2013-05-26, at 10:07 PM, Peter Saint-Andre = wrote: > 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 foo@ve7jtb.com >> 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:foo@ve7jtb.com@google.com =20 >> , but that probably would have confused >> people in itself. > > Standard percent-encoding rules from RFC 3986 allow this: > > acct:foo%40ve7jtb.com@google.com =20 > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger =20 =20 =20 ------=_NextPart_000_02A8_01CE5ACD.F75CE960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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

 

Presently, it says this in Section 4:

=A0=A0 The host to which a WebFinger query is issued = is significant.=A0 If the

=A0=A0 query target contains a "host" = portion (Section 3.2.2 of RFC 3986),

=A0=A0 then the host to which the WebFinger query is = issued MUST be the same

=A0=A0 as the "host" portion of the query = target, unless the client receives

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

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

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

=A0=A0 additional information it = has.

 

I think this is pretty close, though I do wonder whether the = “MAY” in the second sentence should be there.=A0 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:rlb@ipv.sx]
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

 

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=EFvet=E9 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=3D"text/javascript">

  accountchooser.CONFIG.storeAccount =3D = {

    email: = "nikhil_corlett@yahoo.com&quo= t;,

    = displayName: "Nikhil Corlett",

    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"):

 

 

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 <jbradley@pingidentity.com> = wrote:

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

 

I = do think they may tell the site they are on that they sign into Google = as carol@ve7jtb.com , 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

 

 

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:

 

 

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 <melvincarvalho@gmail.com> = wrote:



 

 

On 27 May 2013 04:44, John Bradley <ve7jtb@ve7jtb.com> 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@ve7jtb.com@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:foo@ve7jtb.com 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

Where the acct:foo@ve7jtb.com 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?

 


Thanks
John B.



On 2013-05-26, = at 10:07 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

> 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 foo@ve7jtb.com
>> <mailto:foo@ve7jtb.com> = 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:foo@ve7jtb.com@google.com
>> <mailto:ve7jtb.com@google.com>, but that probably would = have confused
>> people in itself.
>
> Standard = percent-encoding rules from RFC 3986 allow this:
>
> acct:foo%40ve7jtb.com@google.com
>
> = Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>

<= /div>


______________________________________= _________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 

 

 

------=_NextPart_000_02A8_01CE5ACD.F75CE960-- From ve7jtb@ve7jtb.com Mon May 27 09:17:47 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D9121F8E9D for ; Mon, 27 May 2013 09:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmWiWPjlk+vQ for ; Mon, 27 May 2013 09:17:45 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5F421F8E9A for ; Mon, 27 May 2013 09:17:45 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id b11so4603775iee.39 for ; Mon, 27 May 2013 09:17:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=IG2b1AtM+PVwH8k/G0z3adQ1fs0wZK+FTDIKI2OnewI=; b=nBsvRcPSG/t9C+QldQZzOfLenU05YjxzHOgiNGkiz4hdLHf5oTMKh05LAVsQs18VH0 F3hhKCCjrIXaQwuinDfqCghqgICmHK3Kl8NrllBdWhdwzf1iaoaegEuAs8FoulPkmNA7 yrDorqZthijGuduKaNLtWDT63ZUq75cIv6xWASozPa0/12Q9W958bZKfsAZoV/dgeswZ qzqYdxD2lWDOxH+xjZSyWHcSyXAbBDlE+EkvZ+tSzeL1Lqx0YuWpXRBnsMuQJYH3qbwE IsMSfQPGmr7Us8kKWeMb06vR2FIAQojg4Euq5ddfV9LW83fRGIP0iYhL3G683QqqhQno J52Q== X-Received: by 10.42.168.198 with SMTP id x6mr17626762icy.45.1369671464468; Mon, 27 May 2013 09:17:44 -0700 (PDT) Received: from [192.168.1.36] (190-20-31-243.baf.movistar.cl. [190.20.31.243]) by mx.google.com with ESMTPSA id d9sm13720675igr.4.2013.05.27.09.17.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 May 2013 09:17:43 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A612442C-47F2-4923-9BCC-030226315887"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <02a701ce5aef$7e6c8d90$7b45a8b0$@packetizer.com> Date: Mon, 27 May 2013 12:17:29 -0400 Message-Id: <70E4B79D-F5D5-4CB2-9AE8-58B223178A2E@ve7jtb.com> References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> <51A2BFF3.2000208@stpeter.im> <804F2B2A-D2C5-4ADB-BFD3-4F10C0BA6587@ve7jtb.com> <4400A888-77BD-415D-96FB-7B59E1ED9598@ve7jtb.com> <02a701ce5aef$7e6c8d90$7b45a8b0$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQl/rSgEOjtj8OPFlKaf0fX/Zs3xrJ8aaTsZIDgBQVmGg00B2TQ5cNTfAFDZGl+jpBXKd2ZO Cc: 'Peter Saint-Andre' , 'Richard Barnes' , 'John Bradley' , 'Mike Jones' , 'Melvin Carvalho' , 'webfinger' Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 16:17:47 -0000 --Apple-Mail=_A612442C-47F2-4923-9BCC-030226315887 Content-Type: multipart/alternative; boundary="Apple-Mail=_98F0FEF8-5B1E-403D-A421-DF7DB7CF4025" --Apple-Mail=_98F0FEF8-5B1E-403D-A421-DF7DB7CF4025 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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. =46rom 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 "carol@example.com". 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:carol@example.com". 4 WF takes the URI input and extracts the host portion and performs the = following query. GET /.well-known/webfinger? resource=3Dacct%3Acarol%40example.com& rel=3Dhttp%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 alice@example.com 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:alace%40example.com@google.com" 3 The software uses "acct:alace%40example.com@google.com" 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=3Dacct%3Acarol%2540example.com%40google.com& rel=3Dhttp%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. =20= 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" = wrote: > So, are there any changes needed for -14? I think what is wanted is = covered. > =20 > Presently, it says this in Section 4: > 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 = 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. > =20 > I think this is pretty close, though I do wonder whether the =93MAY=94 = in the second sentence should be there. Rather than using a normative = word like that, perhaps just say =93the client chooses a host=94, since = if there is no host portion, the client has no choice: it must have some = other information to guide it. > =20 > Paul > =20 > From: Richard Barnes [mailto:rlb@ipv.sx]=20 > 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 > =20 > tl;dr: We don't need to over-think this. Just allow for hosts to be = explicitly specified in some cases. > =20 > So, I'm trying to think through the use cases here. (Please forgive = my na=EFvet=E9 w.r.t. Account Chooser.) > =20 > 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]: > """ > > """ > =20 > 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. > =20 > 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"): > =20 > = https://identity.example.com/.well-known/webfinger?resource=3Dmailto%3Anik= hil_corlett%40yahoo.com > =20 > 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. > =20 > --Richard > =20 > [1] > =20 > =20 >=20 > On Mon, May 27, 2013 at 8:49 AM, John Bradley = wrote: > I don't think a user is ever going to type in = acct:carol%40ve7jtb.com@google.com nor do I think = acct:113649649235174428485@gmail.com. > =20 > I do think they may tell the site they are on that they sign into = Google as carol@ve7jtb.com , 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. > =20 > The WF spec needs to be clear on what it looks up where. > =20 > One reading of the current spec is that it should look up > =20 > = https://ve7jtb.com/.well-known/webfinger?resource=3Dacct%3Acarol%40ve7tjb.= com > =20 > Mike would tell you he was thinking it would be: > =20 > = https://google.com/.well-known/webfinger?resource=3Dacct%3Acarol%40ve7tjb.= com > =20 > 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: > =20 > = https://google.com/.well-known/webfinger?resource=3Dacct%3Acarol%2540ve7tj= b.com%40google.com > =20 > 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. > =20 > 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. > =20 > John B. > =20 > On 2013-05-27, at 5:53 AM, Melvin Carvalho = wrote: >=20 >=20 > =20 > =20 >=20 > On 27 May 2013 04:44, John Bradley wrote: > That is helpfull. >=20 > 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@ve7jtb.com@google.com to the .well-known at google? >=20 > 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. >=20 > I was thinking that acct:foo@ve7jtb.com would be passed to the = .well-known endpoint. For interoperability this needs to be clear. > =20 > Sorry if I've missed something but would it just be >=20 > = https://google.com/.well-known/webfinger?resource=3Dacct%3Acarol%40ve7tjb.= com >=20 > Where the acct:foo@ve7jtb.com would be part of the the encoded query = string and the @google.com would be part of the origin? >=20 > ie Is the extra @google needed if it's already in the domain part? > =20 >=20 > Thanks > John B. >=20 >=20 > On 2013-05-26, at 10:07 PM, Peter Saint-Andre = wrote: >=20 > > 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 foo@ve7jtb.com > >> 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:foo@ve7jtb.com@google.com > >> , but that probably would have = confused > >> people in itself. > > > > Standard percent-encoding rules from RFC 3986 allow this: > > > > acct:foo%40ve7jtb.com@google.com > > > > Peter > > > > -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > >=20 >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 > =20 > =20 > =20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --Apple-Mail=_98F0FEF8-5B1E-403D-A421-DF7DB7CF4025 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 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.

=46rom 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 = "carol@example.com".
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:carol@example.com".
4 WF takes the = URI input and extracts the host portion and performs the following = query.
GET /.well-known/webfinger?
            resource=3Dacct%3Acarol%40example.com&
            rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fis=
suer
            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 alice@example.com = 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:alace%40example.com@google.com"
3 The software = uses "acct:alace%40example.com@google.com" 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=3Dacct%3Acarol%2540example.com%40google.com&
            rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fis=
suer
            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" <paulej@packetizer.com> = wrote:

So, are there any = changes needed for -14?  I think what is wanted is = covered.
 
Presently, it says this in Section = 4:
   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 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 =93MAY=94 in the second sentence should be = there.  Rather than using a normative word like that, perhaps just = say =93the client chooses a host=94, 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:rlb@ipv.sx] 
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
 
So, I'm trying to think through the use cases here. =  (Please forgive my na=EFvet=E9 w.r.t. Account = Chooser.)
"""
"""
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.

 

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
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:
Sorry if I've missed something but would it just = be

 acct:foo@ve7jtb.com would be part of the the = encoded query string and the @ would = be part of the origin?

stpeter@stpeter.im> = wrote:

> 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 foo@ve7jtb.com
>> = <mailto:ve7jtb.com@google.com
>> <mailto:ve7jtb.com@google.com>, but = that probably would have confused
>> people in = itself.
>
> Standard percent-encoding rules from RFC 3986 = allow this:
>
>   

___________________= ____________________________
webfinger mailing list
webfinger@ietf.org
To: "'John Bradley'" References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> <51A2BFF3.2000208@stpeter.im> <804F2B2A-D2C5-4ADB-BFD3-4F10C0BA6587@ve7jtb.com> <4400A888-77BD-415D-96FB-7B59E1ED9598@ve7jtb.com> <02a701ce5aef$7e6c8d90$7b45a8b0$@packetizer.com> <70E4B79D-F5D5-4CB2-9AE8-58B223178A2E@ve7jtb.com> In-Reply-To: <70E4B79D-F5D5-4CB2-9AE8-58B223178A2E@ve7jtb.com> Date: Tue, 28 May 2013 12:42:26 -0400 Message-ID: <047101ce5bc2$566621c0$03326540$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0472_01CE5BA0.CF57DD20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIGFCMJveTXWbzKSo6DGHvDY3YlOgJh9aLuAegQv70CYfVhSAIOSle3AsggLckA/gss1wEdCMq5AgcQ+QQBO6irjgI32FX5Ah2F1xcBoNYmlpf0pOAA Content-Language: en-us Cc: 'Peter Saint-Andre' , 'Richard Barnes' , 'John Bradley' , 'Mike Jones' , 'Melvin Carvalho' , 'webfinger' Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 16:42:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0472_01CE5BA0.CF57DD20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John, =20 I changed =93MAY choose=94 to =93chooses=94 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. =20 What you describe as Scenario 1 is the only way I had ever expected WebFinger to work (and the only way I=92ve seen WebFinger or Host-Meta implemented). =20 The one =93soft=94 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 =91acct:carol@example.com=92 URI) with a = different host than the host portion specifies. If a client has some reason to believe that=92s the correct thing to do, then fine. How a client knows to do = this I=92d argue is beyond the scope of the WF spec. =20 Paul =20 From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 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 =20 Yes given that there is not host in the URI then change "MAY choose" to "chooses". =20 Your reference for acct: is out of date, it is now Draft 4 May 1, = 2013. =20 >From the recent list discussion it remains under documented how a agent constructs an acct: uri from the inputs. =20 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. =20 So to see if everyone is on the same page, is this correct. =20 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. =20 Scenario 1 (uncontroversial) 1 The software is given a string by the user "carol@example.com". 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:carol@example.com". 4 WF takes the URI input and extracts the host portion and performs the following query. GET /.well-known/webfinger? resource=3Dacct%3Acarol%40example.com& = rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1 Host: example.com =20 5 WF gets response all happy. =20 Scenario 2 (perhaps controversial) 1 The software is told that the userpart is alice@example.com 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:alace%40example.com@google.com" 3 The software uses "acct:alace%40example.com@google.com" 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=3Dacct%3Acarol%2540example.com%40google.com& = rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1 Host: google.com =20 5 WF gets response all happy. =20 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. =20 =20 If everyone thinks scenario 2 was completely obvious and what they were intending to do, then 14 is good. =20 John B. =20 =20 =20 On 2013-05-27, at 11:33 AM, "Paul E. Jones" = wrote: So, are there any changes needed for -14? I think what is wanted is covered. =20 Presently, it says this in Section 4: 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 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. =20 I think this is pretty close, though I do wonder whether the =93MAY=94 = in the second sentence should be there. Rather than using a normative word = like that, perhaps just say =93the client chooses a host=94, since if there = is no host portion, the client has no choice: it must have some other = information to guide it. =20 Paul =20 From: Richard Barnes [mailto:rlb@ipv.sx]=20 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 =20 tl;dr: We don't need to over-think this. Just allow for hosts to be explicitly specified in some cases. =20 So, I'm trying to think through the use cases here. (Please forgive my na=EFvet=E9 w.r.t. Account Chooser.) =20 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]: """ """ =20 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. =20 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"): =20 =20 https://identity.example.com/.well-known/webfinger?resource=3Dmailto%3Ani= khil_ corlett%40yahoo.com =20 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. =20 --Richard =20 [1] < http://accountchooser.net/developers> =20 =20 On Mon, May 27, 2013 at 8:49 AM, John Bradley < jbradley@pingidentity.com> wrote: I don't think a user is ever going to type in acct:carol% 40ve7jtb.com@ google.com nor = do I think acct:113649649235174428485@ gmail.com. =20 I do think they may tell the site they are on that they sign into Google = as carol@ve7jtb.com , 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. =20 The WF spec needs to be clear on what it looks up where. =20 One reading of the current spec is that it should look up =20 https://ve7jtb.com/.well-known/webfinger?resource=3Dacct%3Acarol% 40ve7tjb.com =20 Mike would tell you he was thinking it would be: =20 =20 https://google.com/.well-known/webfinger?resource=3Dacct%3Acarol%40ve7tjb= .com =20 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: =20 =20 https://google.com/.well-known/webfinger?resource=3Dacct%3Acarol%2540ve7t= jb.co m% 40google.com =20 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. =20 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. =20 John B. =20 On 2013-05-27, at 5:53 AM, Melvin Carvalho < melvincarvalho@gmail.com> wrote: =20 =20 On 27 May 2013 04:44, John Bradley < ve7jtb@ve7jtb.com> 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@ ve7jtb.com@ 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:foo@ve7jtb.com would be passed to the .well-known endpoint. For interoperability this needs to be clear. =20 Sorry if I've missed something but would it just be = https://google.com/.well-known/webfinger?resource=3Dacct%3Acarol%40ve7tjb= .com Where the acct:foo@ve7jtb.com 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? =20 Thanks John B. On 2013-05-26, at 10:07 PM, Peter Saint-Andre < = stpeter@stpeter.im> wrote: > 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 foo@ve7jtb.com >> foo@ve7jtb.com> 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:foo@ ve7jtb.com@ google.com >> ve7jtb.com@google.com>, but = that probably would have confused >> people in itself. > > Standard percent-encoding rules from RFC 3986 allow this: > > acct:foo%40ve7jtb.com@google.com > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger =20 =20 =20 _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger =20 ------=_NextPart_000_0472_01CE5BA0.CF57DD20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

John,

 

I changed “MAY choose” to “chooses” and = corrected the reference to the acct URI spec.=A0 Those changes will = appear when we publish the next revision.=A0 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.=A0 Generally, a = client would extract the host portion and direct the query there, just = as you described. =A0However, folks want to be allowed the option to use = the acct URI (not a mangled version, but the = ‘acct:carol@example.com’ URI) with a different host than the = host portion specifies.=A0 If a client has some reason to believe = that’s the correct thing to do, then fine.=A0 How a client knows = to do this I’d argue is beyond the scope of the WF = spec.

 

Paul

 

From:= = John Bradley [mailto:ve7jtb@ve7jtb.com]
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".

 

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)

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:carol@example.com".

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

GET =
/.well-known/webfinger?
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
resource=3Dacct%3Acarol%40example.com&
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fi= ssuer
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
HTTP/1.1
=A0=A0=A0=A0 =
Host: example.com

 

5 WF gets response all = happy.

 

Scenario 2 (perhaps = controversial)

1 The = software is told that the userpart is alice@example.com 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:alace%40example.com@google.com"

=

3 The software uses "acct:alace%40example.com@google.com" as input to = WF.

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

GET =
/.well-known/webfinger?
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
resource=3Dacct%3Acarol%2540example.com%40google.com&
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fi=
ssuer
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
HTTP/1.1
=A0=A0=A0=A0 =
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" <paulej@packetizer.com> = wrote:



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

 

Presently, it says this in Section = 4:

   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 = 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:rlb@ipv.sx] 
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

 

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=EFvet=E9 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=3D"text/javascript">

  accountchooser.CONFIG.storeAccount =3D = {

    = email: "nikhil_corlett@yahoo.com",

    = displayName: "Nikhil = Corlett",

  =   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"):

 

 

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 <jbradley@pingidentity.com> = wrote:

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

 

I do think they may tell the site they are on that = they sign into Google as carol@ve7jtb.com , 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

 

=

 

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:

 

=

 

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 <melvincarvalho@gmail.com> = wrote:




 

 

On 27 May 2013 04:44, John Bradley <ve7jtb@ve7jtb.com> = 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@ve7jtb.com@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:foo@ve7jtb.com 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

Where the acct:foo@ve7jtb.com 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?

 


Thanks
John = B.



On 2013-05-26, at 10:07 PM, Peter = Saint-Andre <stpeter@stpeter.im> = wrote:

> 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 foo@ve7jtb.com
>> = <mailto:foo@ve7jtb.com> 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:foo@ve7jtb.com@google.com
>> <mailto:ve7jtb.com@google.com>, but that = probably would have confused
>> people in = itself.
>
> Standard percent-encoding rules from RFC 3986 = allow this:
>
> acct:foo%40ve7jtb.com@google.com
>= ;
> Peter
>
> --
> Peter = Saint-Andre
> https://stpeter.im/
>
>


______________________________________= _________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 

 

 

_________= ______________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 

------=_NextPart_000_0472_01CE5BA0.CF57DD20-- From prvs=3861e32f63=salvatore.loreto@ericsson.com Wed May 29 00:34:14 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1A221F8EC2 for ; Wed, 29 May 2013 00:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.239 X-Spam-Level: X-Spam-Status: No, score=-105.239 tagged_above=-999 required=5 tests=[AWL=1.010, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHJsT280gbgD for ; Wed, 29 May 2013 00:34:09 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA3221F8F27 for ; Wed, 29 May 2013 00:34:03 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-b7-51a5af6a3c46 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F8.8B.28930.A6FA5A15; Wed, 29 May 2013 09:34:02 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Wed, 29 May 2013 09:34:01 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2F917247A for ; Wed, 29 May 2013 10:34:02 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9A8C55515D for ; Wed, 29 May 2013 10:34:00 +0300 (EEST) Received: from n94.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5AB4750983 for ; Wed, 29 May 2013 10:34:00 +0300 (EEST) Message-ID: <51A5AF69.1050509@ericsson.com> Date: Wed, 29 May 2013 10:34:01 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: webfinger@ietf.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42KZGfG3Vjdr/dJAg03nNCwW3ZjO6MDosWTJ T6YAxihum6TEkrLgzPQ8fbsE7ow9F+cxFjxlqXixbidLA+Mn5i5GTg4JAROJBacfsUDYYhIX 7q1n62Lk4hASOMUoMWHCQ2YIZwOjxKY1W5kgnCuMEntfdoO1CwkcZ5T4cF0GIrGfUWLr1n1g CV4BbYklN/YDdXBwsAioSuzZJQQSZhMwk3j+cAtYiahAssTkqStYIMoFJU7OfAJmiwCdsf7o AzYQW1hAU2Lhs+vsIDazgK3EhTnXWSBseYntb+dAvaAmcfXcJqh7tCR6z3YyTWAUmoVk7Cwk 7bOQtC9gZF7FyJ6bmJmTXm64iREYnAe3/NbdwXjqnMghRmkOFiVxXj3exYFCAumJJanZqakF qUXxRaU5qcWHGJk4OEEEl1QDY52mlsfs+5p3l07Uu/Szu8WtKkq+143l3bN8p/YTH1utdi2f OOW23zJH4bxFwi372VeUXWXPfvPzdUKe1qlc1gerNUImHBL9eszb0zZU0VHeR2Wpz+tpT+ad dZx37HbfSe3Dc2r3hrioznFVMOmed8Bu0qsHTSeCf72edmCy4Ipcv50p101dNiqxFGckGmox FxUnAgBOw3dtIQIAAA== Subject: [webfinger] WebFinger: issues in the Tracker X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 07:34:15 -0000 As you know, the WebFinger draft is still under IESG evaluation, as there are still some DISCUS that need to be cleared. (about DISCUSS in IESG see: http://www.ietf.org/mail-archive/web/webfinger/current/msg00606.html ) I have tried to extrapolate the points/issues that have generated the DISCUS and inserted as issues in the tracker: http://tools.ietf.org/wg/appsawg/trac/report/1 That would provide for sure a more clear perception of the status of the draft, and I hope will also help to speed up the solution of the DISCUS br /Salvatore -- Salvatore Loreto, PhD www.sloreto.com From stpeter@stpeter.im Wed May 29 10:10:57 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EC421F85E6 for ; Wed, 29 May 2013 10:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jhc7KBnzL4Rw for ; Wed, 29 May 2013 10:10:53 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A53F921F970B for ; Wed, 29 May 2013 10:10:53 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CB8DF41111; Wed, 29 May 2013 11:23:41 -0600 (MDT) Message-ID: <51A6369B.9050805@stpeter.im> Date: Wed, 29 May 2013 11:10:51 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Bradley References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> <51A2BFF3.2000208@stpeter.im> <804F2B2A-D2C5-4ADB-BFD3-4F10C0BA6587@ve7jtb.com> <1886C1FF-8693-4114-AAE1-55B0F99E89C9@ve7jtb.com> In-Reply-To: <1886C1FF-8693-4114-AAE1-55B0F99E89C9@ve7jtb.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: webfinger Subject: Re: [webfinger] Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 17:10:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 :) 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: > I don't think a user is ever going to type in > acct:carol%40ve7jtb.com @google.com > nor do I think > acct:113649649235174428485@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 "alice@example.com" as a username at a service, and software might translate that into alice%40example.com@foo.com 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 carol@ve7jtb.com , 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: > > https://google.com/.well-known/webfinger?resource=acct%3Acarol%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: > > 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. So it seems to me. Simpler is better. :-) Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRpjaaAAoJEOoGpJErxa2pNvgQALGdnphMe/vObw0JFDIrb309 bpxzTPLEYp7YD7ym6Aa57Km6uaPPHk2AAE00NrrwfCUzUJSDhc9JbvzyvAGlHlC0 iu/2oqoOmrzxK+mEyKSa9LdDnacL+K7ChdQ5qTp82LZoSd5Uqo6Ii7uPYZvCXFAz 7G/YRxQEhfwx0OI6PjEvr8Z4u+yIw0lZKIOBsDqoI9qznQtAVLr7g0anCa7FRd84 xtJFaknhc+S67RSFB7UrFP0aArcplQ+M9yI2ifcSpINfAbTTvRO3+xoQoDH2s4LK /gz0kHl6MaQaFokknJw2wGe8haHTy+YYwPbcZ9gDlBQyJOOTv5giIKvSCZjKOtVH +u0h9FqKTl4GAnHc9wRRRSRmEI3IxQ41oU11P6nbpOrzM0fR9FVQ8rT9S6q4N/ep 74QX1B72Qh202IyeYwPrViX2IAMJFRyvMgqwjoOdwwWsoYrmK1X6neur0qBNfx59 vspjt8e/I2WJe6hg7B1OwgSi4gwtOnqKcdluCNDYFbIo+98MvoRDgBx41O29lr/G Yp+HlkZXkDQ7UEdXpj31WYTzr5PF3GjcsM28G7uG/d/GwltEv/ZKZDWmRF5TaoLe uAqRQ0pBPJ9KiMaszzlFbHf7E15MuaIl0xn8mcy4T+bgSUtwfCzdfU8CCGTh9VPu 5/jVXn3fSHw8InXbJdWd =Scpt -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed May 29 10:14:09 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03EF21F9743 for ; Wed, 29 May 2013 10:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_41=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K8HcwmbGrsB for ; Wed, 29 May 2013 10:14:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4538621F9729 for ; Wed, 29 May 2013 10:14:05 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3EAA341111; Wed, 29 May 2013 11:26:53 -0600 (MDT) Message-ID: <51A6375A.9000305@stpeter.im> Date: Wed, 29 May 2013 11:14:02 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Paul E. Jones" References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> <51A2BFF3.2000208@stpeter.im> <804F2B2A-D2C5-4ADB-BFD3-4F10C0BA6587@ve7jtb.com> <4400A888-77BD-415D-96FB-7B59E1ED9598@ve7jtb.com> <02a701ce5aef$7e6c8d90$7b45a8b0$@packetizer.com> <70E4B79D-F5D5-4CB2-9AE8-58B223178A2E@ve7jtb.com> <047101ce5bc2$566621c0$03326540$@packetizer.com> In-Reply-To: <047101ce5bc2$566621c0$03326540$@packetizer.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Richard Barnes' , 'John Bradley' , 'Mike Jones' , 'Melvin Carvalho' , 'John Bradley' , 'webfinger' Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 17:14:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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:carol@example.com? 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/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRpjdaAAoJEOoGpJErxa2pDroP/jYhFy/M+jF5Q9Q7+pr28AfA UVCXk9/qQQaI84ys2x5hCZujUtL7mo4csnTRv1mIhjOKsMrTJ8mdDGoUuPCOZOM1 PzDMWuJYjId7cSQQ90bxJIoeml+1Dkg6v1B0caTFzhNj2TIK3hIuoGld7Gv3q1Q0 bscEUl4vRQ+wBKYe9SOxYVnv0xjC5ssdcYYxolgNwIp+c428LZGIKGhQKPDIiBao 3+lRqB53YSWDBKyPEQaQoaA7rUQYzPj74msI1No58OUpNN01d8cRf9fqIgyeMZq3 IzR92eE7v/sFpCq9WBq65OOzhmBmfwgNGeyGZxN4t4bMNaaPHREdGRhXfbgcfT5x 60S5N0RZZ2JBj3v9L/hmmLRz3lka9KM+VyNV5S4OpKwVJFW1Pf1u2hz+qVf1gNK7 dO84QghPD23x34NJzXwc5VC1H0iayiikIVfIBhqTGZKgIUKjp5x0Ph+OcjAjmYvT zefWTm/aWe/mBXNeDTyh0jaf7odbdG+s97H181+aK9hflj6qdc8AxJznFyHUf85K VlpjSiyH0J/eUE3CZb4d5cK2C4HW+c7VPz25wEgAxRI4H6shZ1FCjSWQJv1O9ABD kEj58l9E4xqu+3MUbtnstDIHAGCB33IcD+Z8h0zLc64TysCe8e7Q6XkGzxthT6cB aM707qf6CIc7G1P+NPfE =CdMd -----END PGP SIGNATURE----- From paulej@packetizer.com Wed May 29 12:28:33 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3232521F91CA for ; Wed, 29 May 2013 12:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.577, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KluTqM4wFgO for ; Wed, 29 May 2013 12:28:28 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 38E2121F90C3 for ; Wed, 29 May 2013 12:28:27 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r4TJSPX3019993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 May 2013 15:28:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1369855705; bh=O3UgpXKg45Uk7f3Vd/qrJWJ34te1wvIqMJnaH9PWPZw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=aBNKHTy02QU55jxFye0KAEdlZh5jlZfjV8kmq37MCFyg2nNanHxT8nOPBvK45MV4c ZD6LltNQaUi1G1vxyaNJCVGvYWkXcZi+Wey2+2dxc8In5HxTPnKpDtfEjfiUhFsHtv X8n3mWiIzJ1uT4GY3/SQ5RL/c2kSoBz66foT7vUg= From: "Paul E. Jones" To: "'Peter Saint-Andre'" References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> <51A2BFF3.2000208@stpeter.im> <804F2B2A-D2C5-4ADB-BFD3-4F10C0BA6587@ve7jtb.com> <4400A888-77BD-415D-96FB-7B59E1ED9598@ve7jtb.com> <02a701ce5aef$7e6c8d90$7b45a8b0$@packetizer.com> <70E4B79D-F5D5-4CB2-9AE8-58B223178A2E@ve7jtb.com> <047101ce5bc2$566621c0$03326540$@packetizer.com> <51A6375A.9000305@stpeter.im> In-Reply-To: <51A6375A.9000305@stpeter.im> Date: Wed, 29 May 2013 15:28:32 -0400 Message-ID: <01c301ce5ca2$b4f27910$1ed76b30$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQIGFCMJveTXWbzKSo6DGHvDY3YlOgJh9aLuAegQv70CYfVhSAIOSle3AsggLckA/gss1wEdCMq5AgcQ+QQBO6irjgI32FX5Ah2F1xcBoNYmlgInRJKbAfT0bQyX1XycAA== Content-language: en-us Cc: 'Richard Barnes' , 'John Bradley' , 'Mike Jones' , 'Melvin Carvalho' , 'John Bradley' , 'webfinger' Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 19:28:33 -0000 Peter, > > 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:carol@example.com? 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? 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 stpeter@stpeter.im Wed May 29 15:17:32 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBAB21F871D for ; Wed, 29 May 2013 15:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.932 X-Spam-Level: X-Spam-Status: No, score=-101.932 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_41=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+r7wDy2fUZV for ; Wed, 29 May 2013 15:17:27 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AEE9B21F871C for ; Wed, 29 May 2013 15:17:27 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3CA19411D6; Wed, 29 May 2013 16:30:08 -0600 (MDT) Message-ID: <51A67E6C.3040404@stpeter.im> Date: Wed, 29 May 2013 16:17:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Paul E. Jones" References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> <51A2BFF3.2000208@stpeter.im> <804F2B2A-D2C5-4ADB-BFD3-4F10C0BA6587@ve7jtb.com> <4400A888-77BD-415D-96FB-7B59E1ED9598@ve7jtb.com> <02a701ce5aef$7e6c8d90$7b45a8b0$@packetizer.com> <70E4B79D-F5D5-4CB2-9AE8-58B223178A2E@ve7jtb.com> <047101ce5bc2$566621c0$03326540$@packetizer.com> <51A6375A.9000305@stpeter.im> <01c301ce5ca2$b4f27910$1ed76b30$@packetizer.com> In-Reply-To: <01c301ce5ca2$b4f27910$1ed76b30$@packetizer.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Richard Barnes' , 'John Bradley' , 'Mike Jones' , 'Melvin Carvalho' , 'John Bradley' , 'webfinger' Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 22:17:32 -0000 On 5/29/13 1:28 PM, Paul E. Jones wrote: > Peter, > >>> 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:carol@example.com? 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? > > 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. 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 peter@example.com address and foo.com thinks peter@example.com is the localpart of my acct URI, do we perform the hex-encoding of the '@' character to come up with "acct:peter%40example.com@foo.com"? 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 paulej@packetizer.com Wed May 29 16:40:04 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C4521F9424 for ; Wed, 29 May 2013 16:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePCBRGkfVM7j for ; Wed, 29 May 2013 16:39:59 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B375721F941F for ; Wed, 29 May 2013 16:39:59 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r4TNdvwS001328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 May 2013 19:39:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1369870798; bh=LoZuUiU5MV6watCe88VJRuBAS5B0nz53sJzZdD5qZH8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=EXIRrMP8gSWwgrBohvoZ9EdsZmd01+XRnkXoqa3mgeoDJ8fh8Jow1KNiGAp6r5gzp YVdd8bmniRiy7OtYMCWId5Vl4tEWIfXVPUhos6g28JE4T0jN0ui8B6gLQOO8ix+AUu D8c95sUE5BIB1r7oIRMaRAbd09N1HVyTr0Aad7GU= From: "Paul E. Jones" To: "'Peter Saint-Andre'" References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> <51A2BFF3.2000208@stpeter.im> <804F2B2A-D2C5-4ADB-BFD3-4F10C0BA6587@ve7jtb.com> <4400A888-77BD-415D-96FB-7B59E1ED9598@ve7jtb.com> <02a701ce5aef$7e6c8d90$7b45a8b0$@packetizer.com> <70E4B79D-F5D5-4CB2-9AE8-58B223178A2E@ve7jtb.com> <047101ce5bc2$566621c0$03326540$@packetizer.com> <51A6375A.9000305@stpeter.im> <01c301ce5ca2$b4f27910$1ed76b30$@packetizer.com> <51A67E6C.3040404@stpeter.im> In-Reply-To: <51A67E6C.3040404@stpeter.im> Date: Wed, 29 May 2013 19:40:04 -0400 Message-ID: <023c01ce5cc5$d8e0d8d0$8aa28a70$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQIGFCMJveTXWbzKSo6DGHvDY3YlOgJh9aLuAegQv70CYfVhSAIOSle3AsggLckA/gss1wEdCMq5AgcQ+QQBO6irjgI32FX5Ah2F1xcBoNYmlgInRJKbAfT0bQwB4E6lWgI8uwTRl7TiHZA= Content-language: en-us Cc: 'Richard Barnes' , 'John Bradley' , 'Mike Jones' , 'Melvin Carvalho' , 'John Bradley' , 'webfinger' Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 23:40:04 -0000 Peter, > 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 peter@example.com > address and foo.com thinks peter@example.com is the localpart of my acct > URI, do we perform the hex-encoding of the '@' character to come up with > "acct:peter%40example.com@foo.com"? 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? 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 peter@example.com, 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:peter@foo.com. 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:peter%40example.com@foo.com. Rather, if foo.com wants to provide a WF service and it uses acct:peter@example.com as the account ID, then some system that knows and understands that would issue a query to foo.com using the resource identifier acct:peter@example.com. 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 From paulej@packetizer.com Wed May 29 19:12:48 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C5221F9301 for ; Wed, 29 May 2013 19:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmumAaSZc2wE for ; Wed, 29 May 2013 19:12:43 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 27B7321F8EEC for ; Wed, 29 May 2013 19:12:43 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r4U2Ceeq008891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 May 2013 22:12:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1369879960; bh=HXHh77gDV7RAjAFkk+1CKzaDiLjXXi4roJTtD3DCjlQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=pdG8yhz2gZ6XbWZDU0RYfC5EmC0pVeI8K76G7GsnUhA1ItTfsbnImNPylTfbBOEWI yDUiyfa9dwzcGsu7U1ZXzJdVjiPbJGF/oPAmzkSY2gsHMUhGK2KLX83kFOkhx5R5Z/ BhOY/UUT2AbZBHc8UXIHbeK8+58zWbJHY+Xs5NXE= From: "Paul E. Jones" To: , References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> In-Reply-To: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> Date: Wed, 29 May 2013 22:12:47 -0400 Message-ID: <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-index: AQFNWMcWAQ1n5b22xM4UdUF6Zyw7DZoe/5Qg Content-language: en-us Cc: 'webfinger' Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 02:12:48 -0000 Folks, Sal noted that we have several DISCUSS points to cover. He referred us = to this page: http://tools.ietf.org/wg/appsawg/trac/report/1 Let's take this first item. I'll start with #12 here. =20 The idea with Host-Meta and, hence, WebFinger, is that a client that = wants to know anything about a given URI, it takes the URI and issues a = query as per RFC 6415 or per the WebFinger spec. The intent was to = allow any URI, though if one is looking for information about a user's = account, the recommendation is to use the 'acct' URI, since it is = intended to represent an account owned by a user, versus other URIs like = mailto or http. There may be multiple versions of the story that led us here, but the = problem some were trying to address was the use of http URIs for OpenID. = It was hard for users to use. Users are accustomed to user@domain form = of addresses, but then there was the question of what URI to use for = those. The mailto URI could work, but it was not appropriate if one = were querying for a user on Twitter, for example. That and other = reasons led to the creation of the 'acct' URI scheme. And, so we = recommend the use of that URI scheme in Section 4.5 of the draft. = However, a client most certainly could query for information about a = user using any type of URI. For example, this is valid: $ curl = https://packetizer.com/.well-known/webfinger?resource=3Dhttps%3A%2F%2Fwww= .packetizer.com The expected result is JRD that describes the queried resource. The = most useful resource probably is the 'acct' URI today. The acct URI = would return a JRD that describes the account. So, what is the semantic gap, exactly? What text can we add to make = this clearer without confining WF to being useful only for 'acct' URIs? Paul > -----Original Message----- > From: appsawg issue tracker = [mailto:trac+appsawg@grenache.tools.ietf.org] > Sent: Wednesday, May 29, 2013 3:21 AM > To: draft-ietf-appsawg-webfinger@tools.ietf.org; > salvatore.loreto@ericsson.com > Cc: appsawg@ietf.org > Subject: [appsawg] #12: Semantic gap for the client side >=20 > #12: Semantic gap for the client side >=20 > the document should clarify how the client will be able to 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. >=20 > (This a Discuss, present in the IESG Evaluation Record) >=20 > -- > = -------------------------------------+-----------------------------------= - > - > Reporter: | Owner: = draft-ietf-appsawg- > salvatore.loreto@ericsson.com | webfinger@tools.ietf.org > Type: defect | Status: new > Priority: blocker | Milestone: > Component: webfinger | Version: > Severity: - | Keywords: > = -------------------------------------+-----------------------------------= - > - >=20 > Ticket URL: > appsawg From Michael.Jones@microsoft.com Wed May 29 22:17:52 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCB821F943A for ; Wed, 29 May 2013 22:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQJ2mx4327E0 for ; Wed, 29 May 2013 22:17:48 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id A704621F9512 for ; Wed, 29 May 2013 22:17:47 -0700 (PDT) Received: from BN1BFFO11FD018.protection.gbl (10.58.52.203) by BN1AFFO11HUB017.protection.gbl (10.58.52.127) with Microsoft SMTP Server (TLS) id 15.0.707.0; Thu, 30 May 2013 05:14:33 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD018.mail.protection.outlook.com (10.58.53.78) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Thu, 30 May 2013 05:14:33 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.134]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Thu, 30 May 2013 05:13:09 +0000 From: Mike Jones To: "Paul E. Jones" , "draft-ietf-appsawg-webfinger@tools.ietf.org" , "salvatore.loreto@ericsson.com" Thread-Topic: [webfinger] [appsawg] #12: Semantic gap for the client side Thread-Index: AQFNWMcWAQ1n5b22xM4UdUF6Zyw7DZoe/5QggAA2v3A= Date: Thu, 30 May 2013 05:13:09 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943677C75A3@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> In-Reply-To: <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(13464003)(51704005)(377454002)(47776003)(46406003)(74706001)(74366001)(16406001)(81542001)(81342001)(6806003)(80022001)(76796001)(76786001)(74876001)(50466002)(54356001)(65816001)(46102001)(15202345002)(15395725003)(33656001)(59766001)(74662001)(63696002)(76482001)(56816002)(53806001)(31966008)(54316002)(23726002)(77982001)(56776001)(47976001)(66066001)(51856001)(47446002)(55846006)(79102001)(49866001)(47736001)(50986001)(69226001)(4396001)(20776003)(74502001); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB017; H:TK5EX14MLTC103.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08626BE3A5 Cc: 'webfinger' Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 05:17:52 -0000 It's certainly the case that protocols use WebFinger to look up more than i= dentifiers using e-mail address syntax. For instance, OpenID Connect uses = WebFinger to look up URIs that are URLs. See http://openid.net/specs/openi= d-connect-discovery-1_0.html#URLSyntax. Maybe we could give that example? = We could also give the example of MySpace identifiers, which are URLs. -- Mike -----Original Message----- From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beh= alf Of Paul E. Jones Sent: Wednesday, May 29, 2013 7:13 PM To: draft-ietf-appsawg-webfinger@tools.ietf.org; salvatore.loreto@ericsson.= com Cc: 'webfinger' Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side Folks, Sal noted that we have several DISCUSS points to cover. He referred us to = this page: http://tools.ietf.org/wg/appsawg/trac/report/1 Let's take this first item. I'll start with #12 here. =20 The idea with Host-Meta and, hence, WebFinger, is that a client that wants = to know anything about a given URI, it takes the URI and issues a query as = per RFC 6415 or per the WebFinger spec. The intent was to allow any URI, t= hough if one is looking for information about a user's account, the recomme= ndation is to use the 'acct' URI, since it is intended to represent an acco= unt owned by a user, versus other URIs like mailto or http. There may be multiple versions of the story that led us here, but the probl= em some were trying to address was the use of http URIs for OpenID. It was= hard for users to use. Users are accustomed to user@domain form of addres= ses, but then there was the question of what URI to use for those. The mai= lto URI could work, but it was not appropriate if one were querying for a u= ser on Twitter, for example. That and other reasons led to the creation of= the 'acct' URI scheme. And, so we recommend the use of that URI scheme in= Section 4.5 of the draft. However, a client most certainly could query fo= r information about a user using any type of URI. For example, this is val= id: $ curl https://packetizer.com/.well-known/webfinger?resource=3Dhttps%3A%2F%= 2Fwww.packetizer.com The expected result is JRD that describes the queried resource. The most u= seful resource probably is the 'acct' URI today. The acct URI would return= a JRD that describes the account. So, what is the semantic gap, exactly? What text can we add to make this c= learer without confining WF to being useful only for 'acct' URIs? Paul > -----Original Message----- > From: appsawg issue tracker=20 > [mailto:trac+appsawg@grenache.tools.ietf.org] > Sent: Wednesday, May 29, 2013 3:21 AM > To: draft-ietf-appsawg-webfinger@tools.ietf.org; > salvatore.loreto@ericsson.com > Cc: appsawg@ietf.org > Subject: [appsawg] #12: Semantic gap for the client side >=20 > #12: Semantic gap for the client side >=20 > the document should clarify how the client will be able to determine=20 > what sort of URI to use is the resource part of the query or what=20 > the semantics of any given URI are supposed to be. >=20 > (This a Discuss, present in the IESG Evaluation Record) >=20 > -- > -------------------------------------+-------------------------------- > -------------------------------------+---- > - > Reporter: | Owner: draft-ietf-appsawg- > salvatore.loreto@ericsson.com | webfinger@tools.ietf.org > Type: defect | Status: new > Priority: blocker | Milestone: > Component: webfinger | Version: > Severity: - | Keywords: > -------------------------------------+-------------------------------- > -------------------------------------+---- > - >=20 > Ticket URL: > appsawg _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger From melvincarvalho@gmail.com Thu May 30 01:28:30 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDF521F87FB for ; Thu, 30 May 2013 01:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgOPoMcAcNAP for ; Thu, 30 May 2013 01:28:27 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BD4E521F972D for ; Thu, 30 May 2013 01:27:51 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id fq12so9613756lab.34 for ; Thu, 30 May 2013 01:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OEhz4XVgsNayOEEcgWnQ/1TY7HWHr9jnDP3xGxnkVCg=; b=srBB09eDdvvRnMMWb3JbMbBv1Z2Eia6Ol3dwTKr9Ly3AyxYWApSjEXY3GMPtbAXwUz 3dGwhFYxHghBojZoG9Lcj54tXfTENaJDn8Dy/z7pu+PgjG24ncPeYIjWUM8H6CBrrS80 UOz7uaRX1Ok/4dkQAowEb9OdEnl0hKykFHA9HIuglDSmpLft0/Vp7De+2D6kcjwOssYy 1koz2tpG9z35a8Pqt362Uw8n3eTSiFR2vbUVrlfTM1XUD53WTgTXLZDLGyCRVSVUuP2G H6yOKpRQe0tte1Tr+F0rblHzqSENgHAyoKl7rySxt6Eh2gFjYBW1PW7vxe3a6LdxBeno xLYg== MIME-Version: 1.0 X-Received: by 10.152.5.8 with SMTP id o8mr3052632lao.11.1369902444661; Thu, 30 May 2013 01:27:24 -0700 (PDT) Received: by 10.112.20.231 with HTTP; Thu, 30 May 2013 01:27:24 -0700 (PDT) In-Reply-To: <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> Date: Thu, 30 May 2013 10:27:24 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=089e01419b069751eb04ddeb4440 Cc: salvatore loreto , webfinger , draft-ietf-appsawg-webfinger@tools.ietf.org Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 08:28:31 -0000 --089e01419b069751eb04ddeb4440 Content-Type: text/plain; charset=ISO-8859-1 On 30 May 2013 04:12, Paul E. Jones wrote: > Folks, > > Sal noted that we have several DISCUSS points to cover. He referred us to > this page: > http://tools.ietf.org/wg/appsawg/trac/report/1 > > Let's take this first item. I'll start with #12 here. > > The idea with Host-Meta and, hence, WebFinger, is that a client that wants > to know anything about a given URI, it takes the URI and issues a query as > per RFC 6415 or per the WebFinger spec. The intent was to allow any URI, > though if one is looking for information about a user's account, the > recommendation is to use the 'acct' URI, since it is intended to represent > an account owned by a user, versus other URIs like mailto or http. > > There may be multiple versions of the story that led us here, but the > problem some were trying to address was the use of http URIs for OpenID. > It was hard for users to use. Users are accustomed to user@domain form > of addresses, but then there was the question of what URI to use for those. > The mailto URI could work, but it was not appropriate if one were querying > for a user on Twitter, for example. That and other reasons led to the > creation of the 'acct' URI scheme. And, so we recommend the use of that > URI scheme in Section 4.5 of the draft. However, a client most certainly > could query for information about a user using any type of URI. For > example, this is valid: > $ curl > https://packetizer.com/.well-known/webfinger?resource=https%3A%2F%2Fwww.packetizer.com > > The expected result is JRD that describes the queried resource. The most > useful resource probably is the 'acct' URI today. The acct URI would > return a JRD that describes the account. > > So, what is the semantic gap, exactly? What text can we add to make this > clearer without confining WF to being useful only for 'acct' URIs? > The full text may help here: [[ 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. ]] > > Paul > > > -----Original Message----- > > From: appsawg issue tracker [mailto:trac+appsawg@grenache.tools.ietf.org > ] > > Sent: Wednesday, May 29, 2013 3:21 AM > > To: draft-ietf-appsawg-webfinger@tools.ietf.org; > > salvatore.loreto@ericsson.com > > Cc: appsawg@ietf.org > > Subject: [appsawg] #12: Semantic gap for the client side > > > > #12: Semantic gap for the client side > > > > the document should clarify how the client will be able to 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. > > > > (This a Discuss, present in the IESG Evaluation Record) > > > > -- > > > -------------------------------------+------------------------------------ > > - > > Reporter: | Owner: draft-ietf-appsawg- > > salvatore.loreto@ericsson.com | webfinger@tools.ietf.org > > Type: defect | Status: new > > Priority: blocker | Milestone: > > Component: webfinger | Version: > > Severity: - | Keywords: > > > -------------------------------------+------------------------------------ > > - > > > > Ticket URL: > > appsawg > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > --089e01419b069751eb04ddeb4440 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 30 May 2013 04:12, Paul E. Jones <paulej@packetizer.com> wrote:
Folks,

Sal noted that we have several DISCUSS points to cover. =A0He referred us t= o this page:
http://tools.ietf.org/wg/appsawg/trac/report/1

Let's take this first item. =A0I'll start with #12 here.

The idea with Host-Meta and, hence, WebFinger, is that a client that wants = to know anything about a given URI, it takes the URI and issues a query as = per RFC 6415 or per the WebFinger spec. =A0The intent was to allow any URI,= though if one is looking for information about a user's account, the r= ecommendation is to use the 'acct' URI, since it is intended to rep= resent an account owned by a user, versus other URIs like mailto or http.
There may be multiple versions of the story that led us here, but the probl= em some were trying to address was the use of http URIs for OpenID. =A0It w= as hard for users to use. =A0Users are accustomed to user@domain form of ad= dresses, but then there was the question of what URI to use for those. =A0T= he mailto URI could work, but it was not appropriate if one were querying f= or a user on Twitter, for example. =A0That and other reasons led to the cre= ation of the 'acct' URI scheme. =A0And, so we recommend the use of = that URI scheme in Section 4.5 of the draft. =A0However, a client most cert= ainly could query for information about a user using any type of URI. =A0Fo= r example, this is valid:
$ curl https://packetizer.com/.= well-known/webfinger?resource=3Dhttps%3A%2F%2Fwww.packetizer.com

The expected result is JRD that describes the queried resource. =A0The most= useful resource probably is the 'acct' URI today. =A0The acct URI = would return a JRD that describes the account.

So, what is the semantic gap, exactly? =A0What text can we add to make this= clearer without confining WF to being useful only for 'acct' URIs?=

The full text may help here:

[[
There appears to be a big giant semantic gap for the client side of t= his
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 n= or
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" s= cheme 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 a= nd 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 see= ms 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, "Giv= e
me user provided information, but not config information" or "Giv= e 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-radex= t-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.
]]
=A0

Paul

> -----Original Message-----
> From: appsawg issue tracker [mailto:trac+appsawg@grenache.tools.ietf.org]
> Sent: Wednesday, May 29, 2013 3:21 AM
> To: dra= ft-ietf-appsawg-webfinger@tools.ietf.org;
> salvatore.loreto@eric= sson.com
> Cc: appsawg@ietf.org
> Subject: [appsawg] #12: Semantic gap for the client side
>
> #12: Semantic gap for the client side
>
> =A0the document should clarify how =A0the client will be able to deter= mine
> what
> =A0sort of URI to use is the resource part of the query or
> =A0what the semantics of any given URI are supposed to be.
>
> =A0(This a Discuss, present in the IESG Evaluation Record)
>
> --
> -------------------------------------+--------------------------------= ----
> -
> =A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0= =A0 =A0Owner: =A0draft-ietf-appsawg-
> =A0 salvatore.loreto@= ericsson.com =A0 =A0 =A0| =A0webfinger@tools.ietf.org
> =A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 = =A0 Status: =A0new
> =A0Priority: =A0blocker =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0Milest= one:
> Component: =A0webfinger =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Versio= n:
> =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0= Keywords:
> -------------------------------------+--------------------------------= ----
> -
>
> Ticket URL: <http://tools.ietf.org/wg/appsawg/trac/ticket/12= >
> appsawg <http://tools.ietf.org/appsawg/>


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

--089e01419b069751eb04ddeb4440-- From melvincarvalho@gmail.com Thu May 30 01:41:36 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFC521F9590 for ; Thu, 30 May 2013 01:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lesFSleoTL9I for ; Thu, 30 May 2013 01:41:35 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 08A5321F9298 for ; Thu, 30 May 2013 01:41:34 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id fq12so9623636lab.34 for ; Thu, 30 May 2013 01:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=75QW8oA8PBcQfgo8L1LYR/0KMDtTECpEK2E+Udc4H9Y=; b=mBjKYJxFDNPSqYk6vPGPspp1yKHXOfz1+bC8Fkvlg/0wmC7r8hshy/MhRAZrJt+R+T gNrzIN9Rvntzze+2991h1PhMFShdk3ANlPwXOZMX6IznouDX5IcMw4gOsXUzyM+6tG2p skDIbvffsi6lxCt4mAFwFdGzK2od5eoE2MjBZBLay2tOF41+Pcai6LXOyzXlo54EcmyN r+XDBEqfxMWO/HCWTZd6Wp5geJsSKt9polqPRg9dSmB4qQ6Y77c6mGhu2A1QZUQM6xge e15Ea1HunUVpD6BVfUI8DOBl0guMltZAIG0tO9DWPrdbidJDWDECSr04iyrD4JweTr4M cN+A== MIME-Version: 1.0 X-Received: by 10.152.170.194 with SMTP id ao2mr2998383lac.48.1369903293904; Thu, 30 May 2013 01:41:33 -0700 (PDT) Received: by 10.112.20.231 with HTTP; Thu, 30 May 2013 01:41:33 -0700 (PDT) In-Reply-To: <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> Date: Thu, 30 May 2013 10:41:33 +0200 Message-ID: From: Melvin Carvalho Cc: webfinger Content-Type: multipart/alternative; boundary=089e011615f235bf0304ddeb776c Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 08:41:36 -0000 --089e011615f235bf0304ddeb776c Content-Type: text/plain; charset=ISO-8859-1 On 30 May 2013 04:12, Paul E. Jones wrote: > Folks, > > Sal noted that we have several DISCUSS points to cover. He referred us to > this page: > http://tools.ietf.org/wg/appsawg/trac/report/1 > > Let's take this first item. I'll start with #12 here. > > The idea with Host-Meta and, hence, WebFinger, is that a client that wants > to know anything about a given URI, it takes the URI and issues a query as > per RFC 6415 or per the WebFinger spec. The intent was to allow any URI, > though if one is looking for information about a user's account, the > recommendation is to use the 'acct' URI, since it is intended to represent > an account owned by a user, versus other URIs like mailto or http. > > There may be multiple versions of the story that led us here, but the > problem some were trying to address was the use of http URIs for OpenID. The original OpenID (codename yadis) actually used Linked Data (in particular FOAF) as the discovery method. > It was hard for users to use. This is commonly claimed, but I'm unconvinced. HTTP URIs are delivered in quite a usable way in Facebook. Indeed every browser has an address bar. That doesnt mean that every site visited must be typed in. Point and click, as popuarized by google's reverse search engine, or cut and paste are commonly used by users to get HTTP URIs into the address bar. > Users are accustomed to user@domain form of addresses, but then there was > the question of what URI to use for those. Users are accustomed to real names. That's how friending works on facebook. > The mailto URI could work, but it was not appropriate if one were querying > for a user on Twitter, for example. Account vs User vs Name vs Person seems to come up all over the place. Even in financial accounting its sometimes tricky to distinguish between an account and a person. In truth I think it's a grey area. Trying to get the perfect scheme for this is going to be tricky, just using mailto I think would be fine. > That and other reasons led to the creation of the 'acct' URI scheme. And, > so we recommend the use of that URI scheme in Section 4.5 of the draft. > However, a client most certainly could query for information about a user > using any type of URI. For example, this is valid: > $ curl > https://packetizer.com/.well-known/webfinger?resource=https%3A%2F%2Fwww.packetizer.com > This is problematic because linked data (via HTTP GET) also is an existing discovery process. Can WF ensure interoperability with existing discovery methods? If the client is going to get one result from WF and another from HTTP GET, how does it know which to choose? > > The expected result is JRD that describes the queried resource. The most > useful resource probably is the 'acct' URI today. The acct URI would > return a JRD that describes the account. > > So, what is the semantic gap, exactly? What text can we add to make this > clearer without confining WF to being useful only for 'acct' URIs? > > Paul > > > -----Original Message----- > > From: appsawg issue tracker [mailto:trac+appsawg@grenache.tools.ietf.org > ] > > Sent: Wednesday, May 29, 2013 3:21 AM > > To: draft-ietf-appsawg-webfinger@tools.ietf.org; > > salvatore.loreto@ericsson.com > > Cc: appsawg@ietf.org > > Subject: [appsawg] #12: Semantic gap for the client side > > > > #12: Semantic gap for the client side > > > > the document should clarify how the client will be able to 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. > > > > (This a Discuss, present in the IESG Evaluation Record) > > > > -- > > > -------------------------------------+------------------------------------ > > - > > Reporter: | Owner: draft-ietf-appsawg- > > salvatore.loreto@ericsson.com | webfinger@tools.ietf.org > > Type: defect | Status: new > > Priority: blocker | Milestone: > > Component: webfinger | Version: > > Severity: - | Keywords: > > > -------------------------------------+------------------------------------ > > - > > > > Ticket URL: > > appsawg > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > --089e011615f235bf0304ddeb776c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 30 May 2013 04:12, Paul E. Jones <paulej@packetizer.com> wrote:
Folks,

Sal noted that we have several DISCUSS points to cover. =A0He referred us t= o this page:
http://tools.ietf.org/wg/appsawg/trac/report/1

Let's take this first item. =A0I'll start with #12 here.

The idea with Host-Meta and, hence, WebFinger, is that a client that wants = to know anything about a given URI, it takes the URI and issues a query as = per RFC 6415 or per the WebFinger spec. =A0The intent was to allow any URI,= though if one is looking for information about a user's account, the r= ecommendation is to use the 'acct' URI, since it is intended to rep= resent an account owned by a user, versus other URIs like mailto or http.
There may be multiple versions of the story that led us here, but the probl= em some were trying to address was the use of http URIs for OpenID. =A0

The original OpenID (codename yadis) actually = used Linked Data (in particular FOAF) as the discovery method.
=A0
It was hard for users to= use. =A0

This is commonly claimed, but I&#= 39;m unconvinced.=A0 HTTP URIs are delivered in quite a usable way in Faceb= ook.=A0 Indeed every browser has an address bar.=A0 That doesnt mean that e= very site visited must be typed in.=A0 Point and click, as popuarized by go= ogle's reverse search engine, or cut and paste are commonly used by use= rs to get HTTP URIs into the address bar.=A0
=A0
Users are accustomed to = user@domain form of addresses, but then there was the question of what URI = to use for those. =A0

Users are accustomed to real names.=A0 That's how f= riending works on facebook.=A0
=A0
The mailto URI could work, but it was not appropriate if one were querying = for a user on Twitter, for example. =A0

Acc= ount vs User vs Name vs Person seems to come up all over the place.=A0 Even= in financial accounting its sometimes tricky to distinguish between an acc= ount and a person.=A0 In truth I think it's a grey area.=A0 Trying to g= et the perfect scheme for this is going to be tricky, just using mailto I t= hink would be fine.
=A0
That and other reasons l= ed to the creation of the 'acct' URI scheme. =A0And, so we recommen= d the use of that URI scheme in Section 4.5 of the draft. =A0However, a cli= ent most certainly could query for information about a user using any type = of URI. =A0For example, this is valid:
$ curl https://packetizer.com/.= well-known/webfinger?resource=3Dhttps%3A%2F%2Fwww.packetizer.com

This is problematic because linked data (via HTTP GET) = also is an existing discovery process.=A0 Can WF ensure interoperability wi= th existing discovery methods?=A0 If the client is going to get one result = from WF and another from HTTP GET, how does it know which to choose?
=A0

The expected result is JRD that describes the queried resource. =A0The most= useful resource probably is the 'acct' URI today. =A0The acct URI = would return a JRD that describes the account.

So, what is the semantic gap, exactly? =A0What text can we add to make this= clearer without confining WF to being useful only for 'acct' URIs?=

Paul

> -----Original Message-----
> From: appsawg issue tracker [mailto:trac+appsawg@grenache.tools.ietf.org]
> Sent: Wednesday, May 29, 2013 3:21 AM
> To: dra= ft-ietf-appsawg-webfinger@tools.ietf.org;
> salvatore.loreto@eric= sson.com
> Cc: appsawg@ietf.org
> Subject: [appsawg] #12: Semantic gap for the client side
>
> #12: Semantic gap for the client side
>
> =A0the document should clarify how =A0the client will be able to deter= mine
> what
> =A0sort of URI to use is the resource part of the query or
> =A0what the semantics of any given URI are supposed to be.
>
> =A0(This a Discuss, present in the IESG Evaluation Record)
>
> --
> -------------------------------------+--------------------------------= ----
> -
> =A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0= =A0 =A0Owner: =A0draft-ietf-appsawg-
> =A0 salvatore.loreto@= ericsson.com =A0 =A0 =A0| =A0webfinger@tools.ietf.org
> =A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 = =A0 Status: =A0new
> =A0Priority: =A0blocker =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0Milest= one:
> Component: =A0webfinger =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Versio= n:
> =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0= Keywords:
> -------------------------------------+--------------------------------= ----
> -
>
> Ticket URL: <http://tools.ietf.org/wg/appsawg/trac/ticket/12= >
> appsawg <http://tools.ietf.org/appsawg/>


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

--089e011615f235bf0304ddeb776c-- From paulej@packetizer.com Thu May 30 17:08:31 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B761B21F9948 for ; Thu, 30 May 2013 17:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgICdW8nXwHX for ; Thu, 30 May 2013 17:08:25 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6C72521F9949 for ; Thu, 30 May 2013 17:08:24 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r4V08DII011997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 May 2013 20:08:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1369958894; bh=eEvQ+UtkxfYrb+/PU5WfHQDvB1+rlEh431+VQOFMAQ8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Y63q1KzA/RfQ0JmXxNjZBwvLnp2ZdhWv79nmMaHJpTzFFTrV11xaCuEknNhycL0+f 6WrD3YYMXjyta5YBwWr4WiBYrkVdQxk7P0PflsfD5alHins8kTFIaUSIoa9AolBfsh 9AETtnp5i1zS/122Wj3ccZ8po1jMuMsqLbA+dP2Q= From: "Paul E. Jones" To: "'Melvin Carvalho'" References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> In-Reply-To: Date: Thu, 30 May 2013 20:08:23 -0400 Message-ID: <024301ce5d92$f7d06080$e7712180$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0244_01CE5D71.70C06E30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFNWMcWAQ1n5b22xM4UdUF6Zyw7DQLrgow+AwtEfrKZ8KsfEA== Content-Language: en-us Cc: 'salvatore loreto' , 'webfinger' , draft-ietf-appsawg-webfinger@tools.ietf.org Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 00:08:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0244_01CE5D71.70C06E30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, Thanks for bringing that text forward. All, So, the first part of the issue seems to be one of "what URI do I use and why?" The answer really is "whatever URI you have". The second paragraph goes into one area where I understand why one might be confused. In the example, the client queried the acct URI and just fabricated that by taking the email address (of the form user@domain) and turning that into an account URI. That said, I don't know I would call that a semantic gap. Humans do this. If you see user@domain, you assume it's an email address. Likewise, Microsoft Word will do the same. For WF, there is the suggestion that it's safe to assume it can be converted to acct:user@domain. That might be a faulty assumption, but so might assuming that user@domain is an email address if there is no URI scheme. Even if there were, the intent of the acct URI is to represent user accounts and the expectation is that the form would "look like" email addresses. So, what can we add to the document to make this clearer? The third paragraph goes into use of different URI schemes and the expected results returned. WebFinger should not prescribing exactly what gets returned for any particular URI. The intent of the WF spec is to define the tool used to perform a query and the syntax of the query and response. However, how one actually get configuration information or what information should be returned for a given URI should be defined elsewhere, IMO. We expect that account-related information about a user will be returned if one queries with an acct URI. We do not want to define what is returned for mailto: or xmpp: or other. We might use it for configuration or we may never use those with WebFinger. I would say that should be the scope of another spec. The example in 3.4 is intended to be mysterious. It has been a struggle to provide examples, as some do not like abstract examples and some do not like concrete examples. This is one of the more abstract examples; the device URI scheme does not even exist. The intent of the example is just to show that WF can be used for a range of things, but the syntax is consistent. Why a particular URI scheme is used and exactly what links, properties, etc. will be returned should be defined elsewhere. The last paragraph asks why the resource part is a URI at all. That was debated at length a few years ago when the acct URI scheme was discussed. Blaine Cook was one in favor of using no scheme at all. However, there was a desire to be able to issue a WF query for different URIs, because different URIs might return different responses. I appreciate the immediate question is "what would be different", but I don't think it's the WF spec that should dictate what gets returned for any particular URI. The OpenID specs Mike referenced is a good example that prescribes what to expect using a given URI scheme. The OpenID Connect spec can utilize either the acct URI or an http URI. What words can we introduce that will help to resolve this issue? Paul From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Thursday, May 30, 2013 4:27 AM To: Paul E. Jones Cc: draft-ietf-appsawg-webfinger@tools.ietf.org; salvatore loreto; webfinger Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side On 30 May 2013 04:12, Paul E. Jones wrote: Folks, Sal noted that we have several DISCUSS points to cover. He referred us to this page: http://tools.ietf.org/wg/appsawg/trac/report/1 Let's take this first item. I'll start with #12 here. The idea with Host-Meta and, hence, WebFinger, is that a client that wants to know anything about a given URI, it takes the URI and issues a query as per RFC 6415 or per the WebFinger spec. The intent was to allow any URI, though if one is looking for information about a user's account, the recommendation is to use the 'acct' URI, since it is intended to represent an account owned by a user, versus other URIs like mailto or http. There may be multiple versions of the story that led us here, but the problem some were trying to address was the use of http URIs for OpenID. It was hard for users to use. Users are accustomed to user@domain form of addresses, but then there was the question of what URI to use for those. The mailto URI could work, but it was not appropriate if one were querying for a user on Twitter, for example. That and other reasons led to the creation of the 'acct' URI scheme. And, so we recommend the use of that URI scheme in Section 4.5 of the draft. However, a client most certainly could query for information about a user using any type of URI. For example, this is valid: $ curl https://packetizer.com/.well-known/webfinger?resource=https%3A%2F%2Fwww.pack etizer.com The expected result is JRD that describes the queried resource. The most useful resource probably is the 'acct' URI today. The acct URI would return a JRD that describes the account. So, what is the semantic gap, exactly? What text can we add to make this clearer without confining WF to being useful only for 'acct' URIs? The full text may help here: [[ 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. ]] Paul > -----Original Message----- > From: appsawg issue tracker [mailto:trac+appsawg@grenache.tools.ietf.org ] > Sent: Wednesday, May 29, 2013 3:21 AM > To: draft-ietf-appsawg-webfinger@tools.ietf.org; > salvatore.loreto@ericsson.com > Cc: appsawg@ietf.org > Subject: [appsawg] #12: Semantic gap for the client side > > #12: Semantic gap for the client side > > the document should clarify how the client will be able to 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. > > (This a Discuss, present in the IESG Evaluation Record) > > -- > -------------------------------------+------------------------------------ > - > Reporter: | Owner: draft-ietf-appsawg- > salvatore.loreto@ericsson.com | webfinger@tools.ietf.org > Type: defect | Status: new > Priority: blocker | Milestone: > Component: webfinger | Version: > Severity: - | Keywords: > -------------------------------------+------------------------------------ > - > > Ticket URL: > appsawg _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger ------=_NextPart_000_0244_01CE5D71.70C06E30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

Thanks for bringing that text forward.

 

All,

 

So, the first part of the issue seems to be one of “what URI do = I use and why?”  The answer really is “whatever URI you = have”.

 

The second paragraph goes into one area where I understand why one = might be confused.  In the example, the client queried the acct URI = and just fabricated that by taking the email address (of the form = user@domain) and turning that into an account URI.  That said, I = don’t know I would call that a semantic gap.  Humans do = this.  If you see user@domain, you assume it’s an email = address.  Likewise, Microsoft Word will do the same.  For WF, = there is the suggestion that it’s safe to assume it can be = converted to acct:user@domain.  That might be a faulty assumption, = but so might assuming that user@domain is an email address if there is = no URI scheme.  Even if there were, the intent of the acct URI is = to represent user accounts and the expectation is that the form would = “look like” email addresses.  So, what can we add to = the document to make this clearer?

 

The third paragraph goes into use of different URI schemes and the = expected results returned.  WebFinger should not prescribing = exactly what gets returned for any particular URI.  The intent of = the WF spec is to define the tool used to perform a query and the syntax = of the query and response.  However, how one actually get = configuration information or what information should be returned for a = given URI should be defined elsewhere, IMO.  We expect that = account-related information about a user will be returned if one queries = with an acct URI.  We do not want to define what is returned for = mailto: or xmpp: or other.  We might use it for configuration or we = may never use those with WebFinger.  I would say that should be the = scope of another spec.

 

The example in 3.4 is intended to be mysterious.  It has been a = struggle to provide examples, as some do not like abstract examples and = some do not like concrete examples.  This is one of the more = abstract examples; the device URI scheme does not even exist. The intent = of the example is just to show that WF can be used for a range of = things, but the syntax is consistent.  Why a particular URI scheme = is used and exactly what links, properties, etc. will be returned should = be defined elsewhere.

 

The last paragraph asks why the resource part is a URI at all.  = That was debated at length a few years ago when the acct URI scheme was = discussed.  Blaine Cook was one in favor of using no scheme at = all.  However, there was a desire to be able to issue a WF query = for different URIs, because different URIs might return different = responses.  I appreciate the immediate question is “what = would be different”, but I don’t think it’s the WF = spec that should dictate what gets returned for any particular = URI.  The OpenID specs Mike referenced is a good example that = prescribes what to expect using a given URI scheme.  The OpenID = Connect spec can utilize either the acct URI or an http = URI.

 

What words can we introduce that will help to resolve this = issue?

 

Paul

 

From:= = Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: = Thursday, May 30, 2013 4:27 AM
To: Paul E. Jones
Cc: = draft-ietf-appsawg-webfinger@tools.ietf.org; salvatore loreto; = webfinger
Subject: Re: [webfinger] [appsawg] #12: Semantic gap = for the client side

 

 

 

On 30 May 2013 04:12, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

Sal noted that we have several DISCUSS = points to cover.  He referred us to this page:
http://tools.ietf.org/wg/appsawg/trac/report/1
<= br>Let's take this first item.  I'll start with #12 = here.

The idea with Host-Meta and, hence, WebFinger, is that a = client that wants to know anything about a given URI, it takes the URI = and issues a query as per RFC 6415 or per the WebFinger spec.  The = intent was to allow any URI, though if one is looking for information = about a user's account, the recommendation is to use the 'acct' URI, = since it is intended to represent an account owned by a user, versus = other URIs like mailto or http.

There may be multiple versions of = the story that led us here, but the problem some were trying to address = was the use of http URIs for OpenID.  It was hard for users to use. =  Users are accustomed to user@domain form of addresses, but then = there was the question of what URI to use for those.  The mailto = URI could work, but it was not appropriate if one were querying for a = user on Twitter, for example.  That and other reasons led to the = creation of the 'acct' URI scheme.  And, so we recommend the use of = that URI scheme in Section 4.5 of the draft.  However, a client = most certainly could query for information about a user using any type = of URI.  For example, this is valid:
$ curl https://packetizer.com/.well-known/webfinger?resource=3D= https%3A%2F%2Fwww.packetizer.com

The expected result is JRD = that describes the queried resource.  The most useful resource = probably is the 'acct' URI today.  The acct URI would return a JRD = that describes the account.

So, what is the semantic gap, = exactly?  What text can we add to make this clearer without = confining WF to being useful only for 'acct' URIs?

 

The full text may help here:

[[
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/<= /a>
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.
]]


Paul

> -----Original = Message-----
> From: appsawg issue tracker [mailto:trac+appsawg@grena= che.tools.ietf.org]
> Sent: Wednesday, May 29, 2013 3:21 = AM
> To: draft-ietf-ap= psawg-webfinger@tools.ietf.org;
> salvatore.loreto@ericsson.c= om
> Cc: appsawg@ietf.org
> Subject: = [appsawg] #12: Semantic gap for the client side
>
> #12: = Semantic gap for the client side
>
>  the document = should clarify how  the client will be able to 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.
>
>  (This a Discuss, present in the IESG = Evaluation Record)
>
> --
> = -------------------------------------+-----------------------------------= -
> -
>  Reporter:           =                 |     =  Owner:  draft-ietf-appsawg-
>   salvatore.loreto@ericsson.c= om      |  webfinger@tools.ietf.org
= >      Type:  defect         =           |     Status: =  new
>  Priority:  blocker       =            |  Milestone:
> = Component:  webfinger             =    |    Version:
>  Severity:  - =                     =    |   Keywords:
> = -------------------------------------+-----------------------------------= -
> -
>
> Ticket URL: <http://tools.ietf.org/wg/appsawg/trac/ticket/12>=
> appsawg <http://tools.ietf.org/appsawg/>


_____= __________________________________________
webfinger mailing = list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 

------=_NextPart_000_0244_01CE5D71.70C06E30--