Re: [OAUTH-WG] Simple Web Discovery

John Panzer <jpanzer@google.com> Fri, 29 October 2010 18:33 UTC

Return-Path: <jpanzer@google.com>
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 33B8E3A6A51 for <oauth@core3.amsl.com>; Fri, 29 Oct 2010 11:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.902
X-Spam-Level:
X-Spam-Status: No, score=-105.902 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 hQHipBYO53TS for <oauth@core3.amsl.com>; Fri, 29 Oct 2010 11:33:38 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B57313A6A43 for <oauth@ietf.org>; Fri, 29 Oct 2010 11:33:37 -0700 (PDT)
Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o9TIZV55001453 for <oauth@ietf.org>; Fri, 29 Oct 2010 11:35:31 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1288377331; bh=VNGuYyfAAUU+H1F3mUvuBsDAmWM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZQJEzkeas8nAj65zB+bisFar5yIrf/xIAtc8Sky9qPxVlKWez8EmAQIa/9T2yG5dL jBfSo9Ydw0WpxAakKiSJQ==
Received: from pzk30 (pzk30.prod.google.com [10.243.19.158]) by wpaz5.hot.corp.google.com with ESMTP id o9TIZTc6008192 for <oauth@ietf.org>; Fri, 29 Oct 2010 11:35:30 -0700
Received: by pzk30 with SMTP id 30so158737pzk.28 for <oauth@ietf.org>; Fri, 29 Oct 2010 11:35:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=rNCIlHbD6EgPz1b9eDhbOqfjbSRA9aswFRr302sN9Ss=; b=p0+ohQpK27naZIvTrWcj8Xaq9JDsNMNXur1CCmZvijZn1L3E+ngJR/DwLm6srZ7F5A +GfiAdYG+rJHWjE9vEMg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=wjfE9wlz3X8fREa+tMVpT+xwxA7hTrt/qLDnDWLn6u8l81JuGzQhOmhZYHqB6Xk2KB 5aCwdElov51vHiYbkj3Q==
Received: by 10.142.154.5 with SMTP id b5mr1765752wfe.439.1288377328943; Fri, 29 Oct 2010 11:35:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.185.6 with HTTP; Fri, 29 Oct 2010 11:35:08 -0700 (PDT)
In-Reply-To: <AANLkTimAdES43rtkEA55x6uSE1N2irUZ=_6WHreLH9n0@mail.gmail.com>
References: <4E1F6AAD24975D4BA5B16804296739432459E77D@TK5EX14MBXC207.redmond.corp.microsoft.com> <AANLkTimAdES43rtkEA55x6uSE1N2irUZ=_6WHreLH9n0@mail.gmail.com>
From: John Panzer <jpanzer@google.com>
Date: Fri, 29 Oct 2010 11:35:08 -0700
Message-ID: <AANLkTimaOgXvp9zXqCazt-+Z5KoOm_GDyD7buipYqxVg@mail.gmail.com>
To: Lukas Rosenstock <lr@lukasrosenstock.net>, "webfinger@googlegroups.com" <webfinger@googlegroups.com>
Content-Type: multipart/alternative; boundary=000e0cd2e4380744290493c5b95b
X-System-Of-Record: true
Cc: "openid-specs-ab@lists.openid.net" <openid-specs-ab@lists.openid.net>, "oauth@ietf.org" <oauth@ietf.org>, "openid-specs-connect@lists.openid.net" <openid-specs-connect@lists.openid.net>
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: Fri, 29 Oct 2010 18:33:41 -0000

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?

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?

--
John Panzer / Google
jpanzer@google.com / abstractioneer.org <http://www.abstractioneer.org/> /
@jpanzer



On Fri, Oct 29, 2010 at 4:04 AM, Lukas Rosenstock <lr@lukasrosenstock.net>wrote;wrote:

> Hello!
> This draft is looking nice, the idea and specification is simple and
> straightforward. I would like to draw the connection to other
> discovery approaches.
>
> The introductory example in the draft was this one:
> GET /.well-known/simple-web-discovery?principal=mailto:joe@example.com
> &service=urn:adatum.com:calendar
> HTTP/1.1
>
> This returns the following response:
> {
>  "locations":["http://calendars.proseware.com/calendars/joseph"]
> }
>
> As per my understanding - please correct me if I'm wrong - this should
> be semantically equivalent to the following:
> 1) Perform host-meta discovery for example.com, which returns an XRD
> with the webfinger endpoint.
> 2) Do webfinger for joe@example.com.
> 3) The final XRD contains the following:
> <XRD>
> [...]
> <Link rel="urn:adatum.com:calendar"
> href="http://calendars.proseware.com/calendars/joseph" />
> [...]
> </XRD>
>
> Both approaches work, but SWD is a shortcut removes parsing
> requirements and fetching roundtrips from the client.
>
> Thoughts, anyone?!
>
> Regards,
>  Lukas Rosenstock
>
> 2010/10/27 Mike Jones <Michael.Jones@microsoft.com>om>:
> > Yaron Goland and I are submitting this Simple Web Discovery (SWD) draft
> > (attached and at
> > http://self-issued.info/docs/draft-jones-simple-web-discovery-00.html)
> for
> > consideration by the community to address this need.  SWD is simple to
> > understand and implement, enables different permissions to be applied to
> > discovery of different services, and is JSON-based.  I look forward to
> > discussing this with many of you next week at IIW.
> >
> >
> >
> >                                                                 -- Mike
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>