IETF Logo Mail Archive

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

David Recordon <recordond@gmail.com> Tue, 23 March 2010 17:58 UTC

Return-Path: <recordond@gmail.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 CDAEC3A6CED for <oauth@core3.amsl.com>; Tue, 23 Mar 2010 10:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.437
X-Spam-Level: *
X-Spam-Status: No, score=1.437 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, SARE_URI_CONS7=0.306]
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 TqK6R5AXKZME for <oauth@core3.amsl.com>; Tue, 23 Mar 2010 10:58:28 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id C7B4F3A6C17 for <oauth@ietf.org>; Tue, 23 Mar 2010 10:44:35 -0700 (PDT)
Received: by pvh1 with SMTP id 1so3512625pvh.31 for <oauth@ietf.org>; Tue, 23 Mar 2010 10:44:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=axeObCs4/lJfoM2g7SD5uQHS1NalZEomVqkqhMVc1+A=; b=jb4qT9zIRHzuXnp7oa2q1Kd7uB5bjtEi55T0xhlK2ptzTFNrJhbipH1zrZ5FpvQUTl 5ShOmgOTuGwLFx9/RbBIvvB+lMMbJ/vMlJZh1qrm9xfwbx1/5FVoCF62jun5QYlL54OY Xy2NgziHKCKWXrenhY9DIYJ/wgaCsUnkMZoCY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Pmd4rRxl8KnGrVELmQvbuTkG5/mH3NiVENfSgSxhfaYsFb4/T2iI2YEMQatam9t97i A3lr3JKmibaqENDlXES7v3fI4egyBgXv0/khxqwKRrPsOZdYpJS1bb11RODrvRIOAcup YRyqmUaJzMqk4gQiUmJFaXg5bYpFWxcLCMHkY=
MIME-Version: 1.0
Received: by 10.140.58.10 with SMTP id g10mr4138042rva.85.1269366290559; Tue, 23 Mar 2010 10:44:50 -0700 (PDT)
In-Reply-To: <cb5f7a381003231025l4f662977w2d150e5102ae4bca@mail.gmail.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> <cb5f7a381003231025l4f662977w2d150e5102ae4bca@mail.gmail.com>
Date: Tue, 23 Mar 2010 10:44:50 -0700
Message-ID: <fd6741651003231044m549c87b1h4d361383c001986f@mail.gmail.com>
From: David Recordon <recordond@gmail.com>
To: John Panzer <jpanzer@google.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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:58:29 -0000

Thanks John; incorporated your wording.
http://github.com/daveman692/OAuth-2.0/commit/4c93341a85c70c0954945be636a8dce359fccb0f

On Tue, Mar 23, 2010 at 10:25 AM, John Panzer <jpanzer@google.com> wrote:
> 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.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

v2.23.0 | Report a Bug | By Email