Re: [OAUTH-WG] Simple Web Discovery

Lukas Rosenstock <lr@lukasrosenstock.net> Sun, 31 October 2010 15:20 UTC

Return-Path: <lr@lukasrosenstock.net>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729593A6975 for <oauth@core3.amsl.com>; Sun, 31 Oct 2010 08:20:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4W0jrNbwcbiv for <oauth@core3.amsl.com>; Sun, 31 Oct 2010 08:20:43 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 7251A3A6925 for <oauth@ietf.org>; Sun, 31 Oct 2010 08:20:43 -0700 (PDT)
Received: by gya6 with SMTP id 6so3011977gya.31 for <oauth@ietf.org>; Sun, 31 Oct 2010 08:22:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.190.145 with SMTP id di17mr340414qcb.252.1288538562272; Sun, 31 Oct 2010 08:22:42 -0700 (PDT)
Received: by 10.229.181.213 with HTTP; Sun, 31 Oct 2010 08:22:42 -0700 (PDT)
X-Originating-IP: [91.34.24.149]
In-Reply-To: <AANLkTimaOgXvp9zXqCazt-+Z5KoOm_GDyD7buipYqxVg@mail.gmail.com>
References: <4E1F6AAD24975D4BA5B16804296739432459E77D@TK5EX14MBXC207.redmond.corp.microsoft.com> <AANLkTimAdES43rtkEA55x6uSE1N2irUZ=_6WHreLH9n0@mail.gmail.com> <AANLkTimaOgXvp9zXqCazt-+Z5KoOm_GDyD7buipYqxVg@mail.gmail.com>
Date: Sun, 31 Oct 2010 16:22:42 +0100
Message-ID: <AANLkTi=Ta=O8J1JcTkXpU5+Pw+kB9kOYS5Fxb0QfU2s2@mail.gmail.com>
From: Lukas Rosenstock <lr@lukasrosenstock.net>
To: John Panzer <jpanzer@google.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "openid-specs-connect@lists.openid.net" <openid-specs-connect@lists.openid.net>, "openid-specs-ab@lists.openid.net" <openid-specs-ab@lists.openid.net>, "webfinger@googlegroups.com" <webfinger@googlegroups.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Simple Web Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Oct 2010 15:20:44 -0000

2010/10/29 John Panzer <jpanzer@google.com>om>:
> I think that it would be good to have a writeup like this that describes the
> differences and pros and cons of each approach. Perhaps on a Wiki page?

Feel free to copy this to a wiki page:

1) Server-side requirements:
- XRD/Webfinger: creating .well-known, placing a static host-meta file
with appropriate content type, a Webfinger endpoint which could be
static as well (e.g. by mapping to a file named like the account
identifier)
- SWD: creating .well-known, placing a dynamic endpoint which can
parse the input (requested user and service) and return the output as
one service from a list of services for the user

2) Server delegation:
- XRD/Webfinger: host-meta can point to a third-party host for rel="lrdd"
- SWD: defines its own delegation mechanism based on a JSON file

3) Authentication:
- not fully defined but possible in both approaches via HTTP Basic
authentication or OAuth

4) Consumer-side requirements:
- XRD/Webfinger: fetching host-meta (preferrably with caching),
parsing XML for lrdd endpoint; webfinger request, parsing XML for
required service links
- SWD: one request for user and service, parsing JSON for endpoint;
multiple trips for multiple requests or if redirection is required

5) Network bandwidth requirements:
- XRD/Webfinger: two requests (host-meta and lrdd), of which one is
cacheable for multiple users (same domain); transmission of irrelevant
data is very likely if XRDs are getting bigger
- SWD: one request only, lightweight data; but can become inefficient
if a longer list of services is fetched (individually)

> Some random thoughts:
> One thing:  host-meta is highly cacheable, so the # of round trips will
> hopefully be comparable for large services with significant traffic.  In
> fact the user XRD is also cacheable as well so there can be zero round
> trips.  This proposal defines a mechanism separate from HTTP caching in
> order to cache responses, it'd be good to have a rationale for doing that
> (and to have an explanation of how this should interact with additional HTTP
> level caching.)
> This mechanism appears to require multiple round trips to a server if you
> want to discover multiple services.
> This proposal seems to require that the /well-known provider run a
> significant service on their endpoint, as opposed to just dropping a file in
> place.  I think that the forwarding mechanism may be a way around that?  How
> would I hook into this mechanism if I really only can drop static files on
> my web server, but I can perhaps use cloud services that I've registered
> with to actually power the discovery?

I've tried to include these thoughts in the compilation.

Lukas