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.
- Re: [OAUTH-WG] OAuth 2.0: client_secret, state Richard Barnes
- Re: [OAUTH-WG] First draft of OAuth 2.0 Chuck Mortimore
- [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 Eve Maler
- Re: [OAUTH-WG] First draft of OAuth 2.0 John Panzer
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 Eve Maler
- Re: [OAUTH-WG] First draft of OAuth 2.0 Eve Maler
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- [OAUTH-WG] OAuth 2.0: client_secret, state Manger, James H
- Re: [OAUTH-WG] First draft of OAuth 2.0 Manger, James H
- Re: [OAUTH-WG] OAuth 2.0: client_secret, state Luke Shepard
- Re: [OAUTH-WG] OAuth 2.0: client_secret, state David Recordon
- Re: [OAUTH-WG] OAuth 2.0: client_secret, state Manger, James H
- Re: [OAUTH-WG] OAuth 2.0: client_secret, state Allen Tom
- Re: [OAUTH-WG] OAuth 2.0: client_secret, state David Recordon
- Re: [OAUTH-WG] OAuth 2.0: client_secret, state Richard Barnes
- Re: [OAUTH-WG] First draft of OAuth 2.0 Chuck Mortimore
- Re: [OAUTH-WG] First draft of OAuth 2.0 Mark Mcgloin
- Re: [OAUTH-WG] First draft of OAuth 2.0 Torsten Lodderstedt
- Re: [OAUTH-WG] First draft of OAuth 2.0 John Panzer
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 Torsten Lodderstedt
- Re: [OAUTH-WG] First draft of OAuth 2.0 Paul Madsen
- Re: [OAUTH-WG] First draft of OAuth 2.0 Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth 2.0: client_secret, state Allen Tom
- Re: [OAUTH-WG] First draft of OAuth 2.0 Dick Hardt
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 Chuck Mortimore
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 Brian Eaton
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 Dick Hardt
- Re: [OAUTH-WG] First draft of OAuth 2.0 Dick Hardt
- Re: [OAUTH-WG] First draft of OAuth 2.0 Dick Hardt
- Re: [OAUTH-WG] First draft of OAuth 2.0 Anthony Nadalin
- Re: [OAUTH-WG] First draft of OAuth 2.0 Dick Hardt
- Re: [OAUTH-WG] First draft of OAuth 2.0 Dick Hardt
- Re: [OAUTH-WG] First draft of OAuth 2.0 Torsten Lodderstedt
- Re: [OAUTH-WG] First draft of OAuth 2.0 Chuck Mortimore
- Re: [OAUTH-WG] First draft of OAuth 2.0 Anthony Nadalin
- Re: [OAUTH-WG] First draft of OAuth 2.0 Hans Granqvist
- Re: [OAUTH-WG] First draft of OAuth 2.0 Eve Maler
- Re: [OAUTH-WG] First draft of OAuth 2.0 Eve Maler
- Re: [OAUTH-WG] OAuth 2.0: client_secret, state Marius Scurtescu