Re: [apps-discuss] Webfinger goals doc
John Panzer <jpanzer@google.com> Thu, 29 November 2012 20:08 UTC
Return-Path: <jpanzer@google.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B74D21F8C18 for <apps-discuss@ietfa.amsl.com>; Thu, 29 Nov 2012 12:08:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.698
X-Spam-Level:
X-Spam-Status: No, score=-101.698 tagged_above=-999 required=5 tests=[AWL=-1.278, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_AMP2B=2.555, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUnUoUk07RnD for <apps-discuss@ietfa.amsl.com>; Thu, 29 Nov 2012 12:08:19 -0800 (PST)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42E1C21F8C0B for <apps-discuss@ietf.org>; Thu, 29 Nov 2012 12:08:18 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id y2so12795074lbk.31 for <apps-discuss@ietf.org>; Thu, 29 Nov 2012 12:08:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VG0DLwj7IQX+V42iX+IECASFsN9I/VkPujRtacJp4Dg=; b=QFHnhlD0X2sTomQb8OJFJkyWbFXpDdQCu4KKmkazcR+Xud8UgknieILebfIAPeoTD0 0DRykOLUZ+hwrN5V7+rnKUm9MO4ZoCuB3BHdUYboGE8fUscOAgWL9ZS1W4QB5itnX8N2 UiIzGMU7uzvbJ2lMk0aeZe0n2KopdOGUguJ3VlOTPLTZ2+dWzsnpAX8EN0fut3ZHnu7C /e1rVOM0MSstd7utNGN2sL9QqmvBf2WCq1vltOhcb+86S00jg+jOjZepr786SWmYPmZe aNZEV1/rF2/hAVtPTjYHYY36e/7/xwfFSIoBsKOo8EpNtKNR1ri+zajeeowcthrX9lui tSPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=VG0DLwj7IQX+V42iX+IECASFsN9I/VkPujRtacJp4Dg=; b=eRvFD/OLE6Ftn7ifn64c+OuYHXOrj2si3rYSstJZWvRG3YevVoYatnKh0ZqF7rvjSv ckr5uJBX5OJpFEIYjC42j9LhtABykX6v/fELY7KvQkl2S016zTAsanOezsv5r5+cucLB TRkI0p+d9h4sHwG0449HBOuQIlTQvCCpBKCzQqSU6lCSuvQPmYEggIm2FLBaw22vWeBt NVSYctRvPgstYO2ZNeuoXzYMLBwX/rVlhCQQ/0BW0T/cNWLpaQIPaq+1M8pb4zDAsUKq KP0xEmlfpr8w3BjMVyDU+TuIHiZKLZWPYLy2QlWdvCXLa3KLAVWKEjIgK+GWK23W8Up1 0OgQ==
Received: by 10.112.39.225 with SMTP id s1mr10137269lbk.117.1354219697104; Thu, 29 Nov 2012 12:08:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.59.229 with HTTP; Thu, 29 Nov 2012 12:07:56 -0800 (PST)
In-Reply-To: <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com>
References: <pgauj587ym5drb1i5geo6hem.1354192360769@email.android.com> <CAAJ++qFJK_Crfj7_A6a4E8sPvq6CLYtKZOdDaVEcAp86q7H7wA@mail.gmail.com> <CAAz=sckP2w6-gMfVg-xBBVPcM7wDSerbzdbYXeOY_OpmdbToDQ@mail.gmail.com> <B1DBA05D-BB17-4BBE-893B-490199FC5F5E@ve7jtb.com> <CAAJ++qFfgi2Eu_MBe3drL1zRZJ=x0b5gVgNJ10j6TFimOta4qw@mail.gmail.com> <1268667C-895D-4273-94C8-E057D64FD349@josephholsten.com> <014901cdce6a$6943aaf0$3bcb00d0$@packetizer.com>
From: John Panzer <jpanzer@google.com>
Date: Thu, 29 Nov 2012 12:07:56 -0800
Message-ID: <CAJu8rwX2n54P9prxrqzXZnc-5WeyFoHxhYcD=fvLkfh9FCUU7Q@mail.gmail.com>
To: webfinger@googlegroups.com
Content-Type: multipart/alternative; boundary="485b390f7deafe686504cfa7d7de"
X-Gm-Message-State: ALoCoQmad7o5CU6mVOLuAVQgWO1jLdKEdq1MF5zdmthtIxF3+1CZY0XbPITkQmttnjtViKZ1whKqcKFkUXR3l+SLwX6iORnuKBe/Q3XMV5lsuxj5t09bxi8BG87v4mBrRp+d+bAaofbCGJSaR4nE+WAZ2a1t3sm48IhN3NhjrCZfltIFQztWJjuEhlG7vLSUI5ZtNdGW1XRG
Cc: apps-discuss@ietf.org, Joseph Holsten <joseph@josephholsten.com>
Subject: Re: [apps-discuss] Webfinger goals doc
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Nov 2012 20:08:21 -0000
On Thu, Nov 29, 2012 at 11:47 AM, Paul E. Jones <paulej@packetizer.com>wrote: > There are useful applications of WF where HTTPS is not needed. Could we list those? I'm having trouble coming up with any myself that aren't something like a localhost loopback for testing, frankly. > At the same > time, there is absolutely nothing to prevent an OpenID Connect client from > only using TLS. In fact, I would make that a requirement in OpenID > Connect. > > Paul > > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] On Behalf Of Joseph Holsten > > Sent: Thursday, November 29, 2012 1:53 PM > > To: webfinger@googlegroups.com; apps-discuss@ietf.org > > Subject: Re: [apps-discuss] Webfinger goals doc > > > > Show of hands, who's saying we should support http-sans-tls? > > > > Didn't we agree that supporting small providers was not a goal? I > > seriously can't think of a situation where any site that offers accounts > > to the public should not be expected to run https. > > > > Clearly big fish and motivated vanity domain folks will make it work. > > > > -- > > http://josephholsten.com > > > > On Nov 29, 2012, at 10:18, Breno de Medeiros <breno@google.com> wrote: > > > > > On Thu, Nov 29, 2012 at 9:41 AM, John Bradley <ve7jtb@ve7jtb.com> > > wrote: > > >> Blaine, > > >> > > >> You may be right and openID should not be trying to use WF. > > > > > > + 1 > > > > > >> > > >> There was a lot of pressure put on the two groups to avoid having two > > >> discovery protocols. > > > > > > Yes, and my objective here was to clarify the implications of doing > > > so. With the current write up, it's not feasible to use WF in an authz > > > context. > > > > > >> > > >> As I have said several times, adding the additional requirements for > > >> security to WF may be breaking it for its original more FoF like > > purpose. > > >> > > >> Connect's use case for discovery ls simply finding the IdP > > >> relationship for a identifier the user gives to a RP securely to > > prevent phishing. > > >> We could extract the domain and do a simple https:// GET to the > > >> .well-known/openid-configuration. > > >> > > >> All the other stuff in WF is extraneous to us. Using WF to let a > > >> host provide per account delegation of IdP services is nice in > > >> theory, but may windup compromising both protocols. > > > > > > More is less for security. > > > > > > Let's give up on the goal of re-using WF for OpenIDConnect and allow > > > WF to converge to a solution that is more suitable to its specified > > > goals. > > > > > >> > > >> John B. > > >> > > >> On 2012-11-29, at 2:24 PM, Blaine Cook <romeda@gmail.com> wrote: > > >> > > >> I know I said I wouldn't, but... > > >> > > >> OpenID and other similar protocols handle the verification of domain > > >> & ownership. Any protocol where authn/authz happen will also do this. > > >> > > >> Isn't it safest if we assume that webfinger is for "untrusted" > > >> discovery (like DNS, which still works, thankyouverymuch) and actions > > >> that need more security / authentication should define that > > themselves? > > >> > > >> b. > > >> > > >> On Nov 29, 2012 9:56 AM, "Breno de Medeiros" <breno@google.com> > wrote: > > >>> > > >>> On Thu, Nov 29, 2012 at 4:49 AM, Evan Prodromou <evan@status.net> > > wrote: > > >>>> -1 > > >>>> > > >>>> It's the wrong layer. Defining library interfaces seems out of > > scope. > > >>> > > >>> I don't disagree. But the conclusion from a security perspective > > >>> doesn't change. One shouldn't use WF for security applications such > > >>> as authorization with the currently proposed spec formulation. > > >>> > > >>>> > > >>>> I suggest sticking this in security considerations. > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> Breno de Medeiros <breno@google.com> wrote: > > >>>> > > >>>> TLS downgrade attacks means that you always run a server over HTTP > > >>>> even when you don't provided that the client will fall back to HTTP > > >>>> when HTTPS port is unavailable. The only difference is that the > > >>>> attacker is doing the HTTP hosting instead. > > >>>> > > >>>> If the library for WF is compliant then it will accept downgrade > > >>>> attacks for interoperability. Unless the spec mandates that > > >>>> compliant client implementations must support configurable option > > >>>> to indicate if only HTTPS is allowed (technically the inputs for WF > > >>>> would be an email address and some security flag with a default > > >>>> value that SHOULD be modifiable) we can't expect that compliant WF > > >>>> clients will expose this configuration. And if not we can't use WF > > >>>> as a building block for authentication protocols. It is just a > > >>>> violation of layering if OpenIDConnect will invoke the WF client > > >>>> and then try to second guess what the HTTP client that was wrapped > > >>>> within the WF client did during discovery. > > >>>> > > >>>> On Nov 28, 2012 9:44 PM, "Paul E. Jones" <paulej@packetizer.com> > > wrote: > > >>>>> > > >>>>> One does not need to run the server on both the HTTPS and HTTP > > port. > > >>>>> If > > >>>>> your domain supports HTTPS, run it only on HTTPS. Clients MUST > > >>>>> query there first. > > >>>>> > > >>>>> > > >>>>> > > >>>>> Paul > > >>>>> > > >>>>> > > >>>>> > > >>>>> From: apps-discuss-bounces@ietf.org > > >>>>> [mailto:apps-discuss-bounces@ietf.org] > > >>>>> On Behalf Of Brad Fitzpatrick > > >>>>> Sent: Wednesday, November 28, 2012 12:28 AM > > >>>>> To: webfinger@googlegroups.com > > >>>>> Cc: apps-discuss@ietf.org > > >>>>> Subject: Re: [apps-discuss] Webfinger goals doc > > >>>>> > > >>>>> > > >>>>> > > >>>>> I'm +1 on HTTPS-only too. I plan to run my own webfinger server, > > >>>>> too, and I recognize it'll be more pain since my personal domain > > >>>>> doesn't have certs or an https server running already, but I'm > > >>>>> fine with some inconvenience in exchange for security and simpler > > >>>>> clients. > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Tue, Nov 27, 2012 at 9:18 PM, Mike Jones > > >>>>> <Michael.Jones@microsoft.com> > > >>>>> wrote: > > >>>>> > > >>>>> +1 > > >>>>> > > >>>>> > > >>>>> > > >>>>> From: apps-discuss-bounces@ietf.org > > >>>>> [mailto:apps-discuss-bounces@ietf.org] > > >>>>> On Behalf Of Dick Hardt > > >>>>> Sent: Tuesday, November 27, 2012 9:04 PM > > >>>>> To: webfinger@googlegroups.com > > >>>>> Cc: apps-discuss@ietf.org > > >>>>> Subject: Re: [apps-discuss] Webfinger goals doc > > >>>>> > > >>>>> > > >>>>> > > >>>>> Let's be brave and say HTTPS-only. > > >>>>> > > >>>>> > > >>>>> > > >>>>> Requiring HTTPS enabled OAuth 2.0 to be MUCH simpler than OAuth > > >>>>> 1.0 (yes, a little apples and oranges comparison, but there was a > > >>>>> similar requirement conversation that had the same goal of pushing > > >>>>> complexity to the server from the client -- it also simplifies the > > >>>>> security model) > > >>>>> > > >>>>> > > >>>>> > > >>>>> -- Dick > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Nov 27, 2012, at 6:17 PM, Brad Fitzpatrick > > >>>>> <bradfitz@google.com> > > >>>>> wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>> I just had a chat with Blaine after his recent "I'm out!" email. > > >>>>> I don't think he's actually out--- he's been working on WebFinger > > >>>>> for as long as I have and cares a lot about it. I think he was > > >>>>> just grumpy about the process, speed, and confused about goals and > > >>>>> decisions. > > >>>>> > > >>>>> > > >>>>> > > >>>>> Anyway, we had a very productive conversation on chat and wrote a > > >>>>> doc together to clarify thought processes and decisions: > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> https://docs.google.com/document/d/1Yr00Tr5d71-E6x7VDtmEaC48SendGW > > >>>>> Qe7XcY99pjQWs/edit# > > >>>>> > > >>>>> > > >>>>> > > >>>>> The doc is open for comments. I'll try to keep the doc edited and > > >>>>> neutral. It outlines requirements (aka goals for webfinger), > > >>>>> assumptions, and decisions with pros & cons for each and what > > >>>>> decision was ultimately made and why. > > >>>>> > > >>>>> > > >>>>> > > >>>>> The decisions are I'm sure subject to change, but hopefully not > > >>>>> too much. > > >>>>> > > >>>>> > > >>>>> > > >>>>> Let me know what I missed. > > >>>>> > > >>>>> > > >>>>> > > >>>>> My apologies if you don't like the document's medium or fluidity, > > >>>>> but it's the tool I have to work with, and better than nothing. > > >>>>> If you object to the fluidity and want something concrete to reply > > >>>>> to in email, I've snapshotted the document to http://goo.gl/fTMC1 > > >>>>> but I won't accept comments or make changes there. Use whatever > > >>>>> mechanism you prefer. > > >>>>> > > >>>>> > > >>>>> > > >>>>> - Brad > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> Copy of doc for posterity: > > >>>>> > > >>>>> > > >>>>> > > >>>>> WebFinger Goals, Assumptions, and Decisions (SNAPSHOT1) > > >>>>> > > >>>>> aka background reading on understanding the WebFinger spec > > >>>>> > > >>>>> Requirements > > >>>>> > > >>>>> > > >>>>> > > >>>>> given just a string that looks like "user@host.com", find a > > >>>>> machine-readable metadata document. > > >>>>> > > >>>>> background: since the death of the "finger" protocol (from which > > >>>>> webfinger > > >>>>> gets its name), email-looking identifiers like "user@host.com" > > have > > >>>>> been > > >>>>> write-only: you can email it (maybe, if it speaks SMTP), but you > > can't > > >>>>> do > > >>>>> any read/discovery operations on it. You can't find its supported > > or > > >>>>> preferred protocols, its name, its avatar, its public key, its > > >>>>> identity/social/blog server, etc. > > >>>>> the format of the identifier matters because people ("regular > > users") > > >>>>> effortlessly identify with their email addresses, and already use > > them > > >>>>> for > > >>>>> sharing outside (and inside) of social networks > > >>>>> > > >>>>> corollary: WebFinger is not about doing discovery on URLs or URIs > > or > > >>>>> IRIs > > >>>>> or XRIs or any other "dorky" identifier. Webfinger is about doing > > a > > >>>>> discovery (read) operation on something a non-technical user would > > >>>>> write on > > >>>>> a napkin or give you on a business card. > > >>>>> > > >>>>> clients can be implemented in browsers in JavaScript > > >>>>> > > >>>>> corollary: CORS shout-out in spec > > >>>>> corollary: no DNS component > > >>>>> > > >>>>> delegation to webfinger-as-a-service by larger providers from > > >>>>> self-hosted > > >>>>> or organisational domains is possible (cf. DNS NS records) > > >>>>> latency of updates must be low (unlike DNS) > > >>>>> no service provider (no company) is special-cased. > > >>>>> > > >>>>> Assumptions > > >>>>> > > >>>>> > > >>>>> > > >>>>> the string "user@host.com" is NOT necessarily an email address, > > even > > >>>>> though most people today associate it with an email address. > > >>>>> > > >>>>> corollary: the "acct:" URI scheme and draft-ietf-appsawg-acct-uri- > > 01 > > >>>>> etc > > >>>>> > > >>>>> complexity in specs leads to few and/or poor implementations and > > >>>>> ultimately hinders adoption > > >>>>> > > >>>>> corollary: value simplicity wherever possible, even if it means > > some > > >>>>> things are harder or not possible for some parties. > > >>>>> i.e. we'd rather have a 3 page spec that makes 90% of people happy > > >>>>> rather > > >>>>> than a 30 page spec that makes 95% of people happy, especially if > > such > > >>>>> a > > >>>>> smaller spec means a much improved chance of adoption. > > >>>>> > > >>>>> obvious, but: optional parts in specs need to be optional for only > > one > > >>>>> party (client or server) and required for the other. > > >>>>> > > >>>>> i.e. there needs to always be an intersection of features in the > > spec > > >>>>> that > > >>>>> both parties support. e.g. can't have both clients and servers > > decide > > >>>>> to > > >>>>> only speak > > >>>>> > > >>>>> there will be more clients than servers > > >>>>> > > >>>>> corollary: it should be easier to write/run a client than a server > > >>>>> > > >>>>> few users own their own domain name and will run their own > > identity > > >>>>> server > > >>>>> > > >>>>> . and those that do own their own domain name will mostly want to > > >>>>> delegate > > >>>>> management of their webfinger profiles or will know what they're > > doing > > >>>>> and > > >>>>> therefore don't need to be catered to. > > >>>>> further assumption: most will be running Wordpress or some such > > >>>>> software > > >>>>> already. > > >>>>> corollary: we don't have to cater to this small audience much.. > > they'll > > >>>>> know what they're doing, or their hosting software will. > > >>>>> > > >>>>> should be easy to do both client and server. Ideal solution > > balances > > >>>>> both > > >>>>> (delegation for simpler servers)? > > >>>>> standards MUST be programmer-friendly > > >>>>> > > >>>>> Decisions > > >>>>> > > >>>>> > > >>>>> > > >>>>> HTTP vs DNS > > >>>>> > > >>>>> DNS (SRV, TXT, etc) precludes JavaScript clients (as of 2006-2012), > > so > > >>>>> rejected. HTTP instead. > > >>>>> > > >>>>> JSON vs XML > > >>>>> > > >>>>> Per assumption above, we needed to pick at least one as required. > > We > > >>>>> chose JSON. If both parties advertise (via HTTP headers) that > > they > > >>>>> prefer > > >>>>> XML, that's fine. JSON is easier for JavaScript clients, as one > > >>>>> advantage. > > >>>>> It's also simpler to read on the page (per the complexity > > argument). > > >>>>> But > > >>>>> both are small arguments and not worth arguing about. At the end > > of > > >>>>> the day > > >>>>> a decision had to be made, and it was. > > >>>>> > > >>>>> HTTP-ish (Accept / Link headers, etc) vs well-known path > > >>>>> > > >>>>> > > >>>>> > > >>>>> HTTP-ish is more proper, but viewed as too hard for servers to > > route > > >>>>> (routing on headers, rather than request paths) and more > > importantly > > >>>>> too > > >>>>> hard for clients to send (setting headers). > > >>>>> well-known URLs (like /favicon.ico) are gross, though. > > >>>>> Decision: use a well-known URL. > > >>>>> We defined RFC 5785 first instead, to make using a well-known path > > less > > >>>>> offensive. > > >>>>> > > >>>>> One HTTP request vs two. > > >>>>> > > >>>>> Two requests: clients first fetch /.well-known/host-meta (to find > > where > > >>>>> to > > >>>>> do a webfinger query), then fetch that. > > >>>>> > > >>>>> PRO: the host-meta document can be a static file, which makes > > >>>>> delegation > > >>>>> to other webfinger service providers easier for custom domains. > > >>>>> CON: twice the latency, especially for mobile > > >>>>> CON: extra client complexity > > >>>>> > > >>>>> One request: clients just do a query immediately to > > >>>>> /.well-known/webfinger, without consulting host-meta. > > >>>>> > > >>>>> PRO: half the latency > > >>>>> PRO: less client complexity > > >>>>> CON: service providers may need to reverse-proxy the query to the > > right > > >>>>> backend. > > >>>>> CON: harder for small domain names with static webservers to > > delegate. > > >>>>> > > >>>>> Decision: Just one HTTP requests, because we care more about > > client > > >>>>> simplicity than server simplicity. > > >>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> apps-discuss mailing list > > >>>>> apps-discuss@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/apps-discuss > > >>>>> > > >>>>> ... > > >>> > > >>> > > >>> > > >>> -- > > >>> --Breno > > >>> _______________________________________________ > > >>> apps-discuss mailing list > > >>> apps-discuss@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/apps-discuss > > >> > > >> _______________________________________________ > > >> apps-discuss mailing list > > >> apps-discuss@ietf.org > > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > > > > > > > -- > > > --Breno > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > >
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- Re: [apps-discuss] Webfinger goals doc John Bradley
- Re: [apps-discuss] Webfinger goals doc Dick Hardt
- Re: [apps-discuss] Webfinger goals doc Mike Jones
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- Re: [apps-discuss] Webfinger goals doc Sandeep Shetty
- Re: [apps-discuss] Webfinger goals doc John Bradley
- Re: [apps-discuss] Webfinger goals doc John Bradley
- Re: [apps-discuss] Webfinger goals doc Melvin Carvalho
- Re: [apps-discuss] Webfinger goals doc Paul Hoffman
- Re: [apps-discuss] Webfinger goals doc Dick Hardt
- Re: [apps-discuss] Webfinger goals doc Ben Laurie
- [apps-discuss] Webfinger goals doc Brad Fitzpatrick
- Re: [apps-discuss] Webfinger goals doc Brad Fitzpatrick
- Re: [apps-discuss] Webfinger goals doc Brad Fitzpatrick
- Re: [apps-discuss] Webfinger goals doc Brad Fitzpatrick
- Re: [apps-discuss] Webfinger goals doc John Bradley
- Re: [apps-discuss] Webfinger goals doc Phillip Hallam-Baker
- Re: [apps-discuss] Webfinger goals doc Joe Gregorio
- Re: [apps-discuss] Webfinger goals doc Breno de Medeiros
- Re: [apps-discuss] Webfinger goals doc William Mills
- Re: [apps-discuss] Webfinger goals doc Martin J. Dürst
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- Re: [apps-discuss] Webfinger goals doc Breno de Medeiros
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- Re: [apps-discuss] Webfinger goals doc Evan Prodromou
- Re: [apps-discuss] Webfinger goals doc John Bradley
- Re: [apps-discuss] Webfinger goals doc John Bradley
- Re: [apps-discuss] Webfinger goals doc Breno de Medeiros
- Re: [apps-discuss] Webfinger goals doc Breno de Medeiros
- Re: [apps-discuss] Webfinger goals doc Blaine Cook
- Re: [apps-discuss] Webfinger goals doc John Bradley
- Re: [apps-discuss] Webfinger goals doc Breno de Medeiros
- Re: [apps-discuss] Webfinger goals doc William Mills
- Re: [apps-discuss] Webfinger goals doc Joseph Holsten
- Re: [apps-discuss] Webfinger goals doc Evan Prodromou
- Re: [apps-discuss] Webfinger goals doc Tim Bray
- Re: [apps-discuss] Webfinger goals doc John Bradley
- Re: [apps-discuss] Webfinger goals doc Evan Prodromou
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- Re: [apps-discuss] Webfinger goals doc Breno de Medeiros
- Re: [apps-discuss] Webfinger goals doc Evan Prodromou
- Re: [apps-discuss] Webfinger goals doc William Mills
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- Re: [apps-discuss] Webfinger goals doc Evan Prodromou
- Re: [apps-discuss] Webfinger goals doc William Mills
- Re: [apps-discuss] Webfinger goals doc Breno de Medeiros
- Re: [apps-discuss] Webfinger goals doc John Bradley
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- Re: [apps-discuss] Webfinger goals doc Breno de Medeiros
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- Re: [apps-discuss] Webfinger goals doc Breno de Medeiros
- Re: [apps-discuss] Webfinger goals doc John Panzer
- Re: [apps-discuss] Webfinger goals doc William Mills
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- Re: [apps-discuss] Webfinger goals doc Joseph Anthony Pasquale Holsten
- Re: [apps-discuss] Webfinger goals doc John Panzer
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- Re: [apps-discuss] Webfinger goals doc Joseph Holsten
- Re: [apps-discuss] Webfinger goals doc Dick Hardt
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- Re: [apps-discuss] Webfinger goals doc Breno de Medeiros
- Re: [apps-discuss] Webfinger goals doc William Mills
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Dick Hardt
- Re: [apps-discuss] Webfinger goals doc Mike Jones
- Re: [apps-discuss] Webfinger goals doc John Panzer
- Re: [apps-discuss] Webfinger goals doc t.petch
- Re: [apps-discuss] Webfinger goals doc Bob Wyman
- [apps-discuss] R: Webfinger goals doc Goix Laurent Walter
- Re: [apps-discuss] Webfinger goals doc John Bradley
- Re: [apps-discuss] Webfinger goals doc John Bradley
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- Re: [apps-discuss] Webfinger goals doc Breno de Medeiros
- Re: [apps-discuss] Webfinger goals doc Tim Bray
- Re: [apps-discuss] Webfinger goals doc Brad Fitzpatrick
- Re: [apps-discuss] Webfinger goals doc Brad Fitzpatrick
- Re: [apps-discuss] Webfinger goals doc Brad Fitzpatrick
- Re: [apps-discuss] Webfinger goals doc Zellyn Hunter
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- Re: [apps-discuss] Webfinger goals doc Bob Wyman
- Re: [apps-discuss] Webfinger goals doc John Bradley
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Nico Williams
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- Re: [apps-discuss] Webfinger goals doc John Bradley
- Re: [apps-discuss] Webfinger goals doc Paul E. Jones
- Re: [apps-discuss] Webfinger goals doc John Bradley
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Nico Williams
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP James M Snell
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Nico Williams
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP John Bradley
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP James M Snell
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Nico Williams
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Bob Wyman
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Breno de Medeiros
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Tim Bray
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Martin Thomson
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Breno de Medeiros
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Tim Bray
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Nico Williams
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Nico Williams
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Blaine Cook
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP William Mills
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Evan Prodromou
- Re: [apps-discuss] Webfinger goals doc Brad Fitzpatrick
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Brad Fitzpatrick
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP John Bradley
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP John Bradley
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Tim Bray
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Tim Bray
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Tim Bray
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Nico Williams
- [apps-discuss] Options... Re: HTTPS-only vs HTTPS… William Mills
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Paul E. Jones
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP John Bradley
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Paul E. Jones
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Mikael Nordfeldth
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Melvin Carvalho
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Dick Hardt
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Brad Fitzpatrick
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Zellyn Hunter
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Nico Williams
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Paul E. Jones
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Dick Hardt
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Dick Hardt
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Nico Williams
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Nico Williams
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Dick Hardt
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Dick Hardt
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Nico Williams
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Dick Hardt
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP John Panzer
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Dick Hardt
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Paul E. Jones
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Paul E. Jones
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Tim Bray
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Paul E. Jones
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Tim Bray
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Martin J. Dürst
- Re: [apps-discuss] Web Finger HTTPS-only vs HTTPS… John Bradley
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Nico Williams
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Evan Prodromou
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Nico Williams
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP John Panzer
- Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP Brad Fitzpatrick