Re: [OAUTH-WG] First draft of OAuth 2.0

John Panzer <jpanzer@google.com> Tue, 23 March 2010 17:25 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 7A8C63A6C01 for <oauth@core3.amsl.com>; Tue, 23 Mar 2010 10:25:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.093
X-Spam-Level:
X-Spam-Status: No, score=-98.093 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, 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 lWKdyyYgdcrp for <oauth@core3.amsl.com>; Tue, 23 Mar 2010 10:25:29 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id B994B3A6BB1 for <oauth@ietf.org>; Tue, 23 Mar 2010 10:25:28 -0700 (PDT)
Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [10.3.21.12]) by smtp-out.google.com with ESMTP id o2NHPkTV014134 for <oauth@ietf.org>; Tue, 23 Mar 2010 18:25:46 +0100
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1269365146; bh=S8y3YAubXT9/7nz03Ely2P9Z6DA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Hs/zyxRtwkmvxFtBAIFJIEeZrrV0s3FbqSY//J9rB3AQbASYmkzliy36Ga8b33PLJ iQRNoFV3gkKep1daOzHLg==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=X4gGsq/B3i3z8sSGVvNgnmDrR4mQixhYAY/RC0ZEo8WOKcqBotVOHejrsiInm5vYA 7jKqG1k5FFKK+cHyQdEyg==
Received: from pvf33 (pvf33.prod.google.com [10.241.210.97]) by hpaq12.eem.corp.google.com with ESMTP id o2NHPZ0t021300 for <oauth@ietf.org>; Tue, 23 Mar 2010 18:25:45 +0100
Received: by pvf33 with SMTP id 33so3105111pvf.32 for <oauth@ietf.org>; Tue, 23 Mar 2010 10:25:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.250.10 with SMTP id x10mr1252874wfh.341.1269365143602; Tue, 23 Mar 2010 10:25:43 -0700 (PDT)
In-Reply-To: <7477F0EE-4878-4D91-9DE2-7D013AFE415D@xmlgrrl.com>
References: <526C3C44-18CF-4A94-A4C6-72702F73AC83@facebook.com> <DEDA56D8-EF7C-4BD1-97E9-B9415424F328@xmlgrrl.com> <cb5f7a381003211253l19906650j5382a66116416016@mail.gmail.com> <BFD74694-412D-47EB-9481-6E3CAD5D6E40@facebook.com> <7477F0EE-4878-4D91-9DE2-7D013AFE415D@xmlgrrl.com>
From: John Panzer <jpanzer@google.com>
Date: Tue, 23 Mar 2010 10:25:23 -0700
Message-ID: <cb5f7a381003231025l4f662977w2d150e5102ae4bca@mail.gmail.com>
To: Eve Maler <eve@xmlgrrl.com>
Content-Type: multipart/alternative; boundary="001636ed68367985ce04827b1a77"
X-System-Of-Record: true
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] First draft of OAuth 2.0
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: Tue, 23 Mar 2010 17:25:30 -0000

On Sun, Mar 21, 2010 at 6:12 PM, Eve Maler <eve@xmlgrrl.com> wrote:

> On 21 Mar 2010, at 1:43 PM, David Recordon wrote:
>
> > The goal of the, "the authorization server advertises (such as via
> documentation) the URIs of the following three endpoints" wording was to
> allow for a discovery process that is defined separately from this spec.  Is
> that unclear?  Have other words to propose?
>
> So perhaps this wants to be a thin spec that can be combined with the OAuth
> core spec, if there's general interest in it.  (In the UMA spec, we were
> already in the position of making up some XRD to describe a couple of WRAP
> endpoints, along with UMA endpoints and metadata.  It would be nice to have
> a canonical version of the former, at the least.)
>

So,

Minimally, perhaps the spec should say "advertises (such as via
documentation or discovery process beyond the scope of this document) the
URIs of the following three endpoints..."  just to give people a heads up
that there may be external auto-discovery happening.

Beyond that, it might be nice to see if there could be a separate, svelte
auth discovery document of some sort, even if not part of the core spec.
 Even something UMA-specific could serve as a good example for others.

My main worry is that SPs might start to think that they can do all kinds of
arbitrary things in their documentation to find the endpoints (register here
to generate the endpoints for your app, etc.) and thus go down a path that
means they can't ever participate in auto-discovery.  Which is a fine path
if they explicitly decide they don't care about auto-discovery and interop,
but a poor path if they just didn't see the signs about the quicksand and
alligators and non-interoperability.