Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery

Brian Campbell <bcampbell@pingidentity.com> Tue, 02 February 2016 23:02 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAA51A8BC1 for <oauth@ietfa.amsl.com>; Tue, 2 Feb 2016 15:02:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boy3cTknlArN for <oauth@ietfa.amsl.com>; Tue, 2 Feb 2016 15:02:44 -0800 (PST)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F28B1A8AC2 for <oauth@ietf.org>; Tue, 2 Feb 2016 15:02:44 -0800 (PST)
Received: by mail-ig0-x236.google.com with SMTP id t15so72945917igr.0 for <oauth@ietf.org>; Tue, 02 Feb 2016 15:02:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=igdJY7kjOzvap8OCFWTVRY5g86KpkaAJD0XFheo0L+A=; b=dFSHKi+fmkuoSXL/CiLUA97pFGZUNIvpDkm+bQkm0axDWJMjeDvje3agxf7rp6HqTA XqIu9V5ljvWjhpu9BorPMUMuuo2utQJQs4r+KABqJASZHTna1GwJQ0yvy5AxaYj/QzGJ AMVDny86Qfm7D4ZcdwoU2EKVAHNNhWmOB2TMw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=igdJY7kjOzvap8OCFWTVRY5g86KpkaAJD0XFheo0L+A=; b=NGNbJdq/vw/9vyBZjKVWcAXqRlvSEjh7OuRw9O+kqAQPDGn8SPGDqezxVOX63f5aJ0 0bcEBJJJf8lOHtmdCelmhMu7Ef3b9pi4JQ4uor81pm29VSFf8XhpsX2j9XCqn4bUd0FL QSTfHla8y6neX4PKJb0Nstgp2WwwpXnDb9NCnar5kKHEiJ2MnkS1r008SDCnOl78nWVO JhDEzMTD9+y3xUA10sDw+Sdd5JUwWSOwm10hy1W8t78LeGQ77nbA9Fc/SBUgf3ogZx1D 3tfaHHAKuZnHJtwVkYzq5sM7e8+egQTFCpNpuECzjH+oxlyTcaorS1LoDATlKjB8wOEN M0Hg==
X-Gm-Message-State: AG10YOQxUySrALwN9H6rTK0pIuG/3L/XaNpOFkoVY/HIYSetEZfzXawLpuQZ+g35QKPGfgYqHsfh0zCkcJSx1a31
X-Received: by 10.50.4.3 with SMTP id g3mr20727410igg.49.1454454163408; Tue, 02 Feb 2016 15:02:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.212.69 with HTTP; Tue, 2 Feb 2016 15:02:13 -0800 (PST)
In-Reply-To: <56A7CA7D.3050602@lodderstedt.net>
References: <569E2298.3010508@gmx.net> <56A7CA7D.3050602@lodderstedt.net>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 2 Feb 2016 16:02:13 -0700
Message-ID: <CA+k3eCS6_wZ0YkG8HjiwmQGemndHRBCG12McNTsgTvuEch5LwQ@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: multipart/alternative; boundary=001a11c3bd18c0a688052ad17f27
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/UeQ7fa6ljGKTwNA64LToGwdzX1s>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 02 Feb 2016 23:02:46 -0000

I agree (kind of anyway) with Torsten. Discovery based on the user id of
the resource owner doesn't necessarily make sense for general OAuth cases.

Also restating what I already posted about the draft: Would it be worth
considering constraining the scope of this document to just the publication
and content of AS metadata? And keep the actual discovery of that metadata,
be it from the RS or the user id or what have you, out of scope or in a
different document(s)? The former is relatively well understood and
provides some value. While the ideas about how the the latter should work
seem to have a pretty broad range.

On Tue, Jan 26, 2016 at 12:35 PM, Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> Hi,
>
> I support the adoption of this document as starting point for our work
> towards OAuth discovery.
>
> Restating what I already posted after the last IETF meeting: It seems the
> document assumes the AS can always be discoverd using the user id of the
> resource owner. I think the underlying assumption is resource servers
> accept access token of different (any?) user specific AS (and OP)? From my
> perspective, RSs nowadays typically trust _the_ AS of their security
> domain/ecosystem and all resource owners need to have an user account with
> this particular AS. So I would assume the process to start at the RS. I
> think the spec needs to cover the latter case as well.
>
> kinds regards,
> Torsten.
>
>
> Am 19.01.2016 um 12:48 schrieb Hannes Tschofenig:
>
> Hi all,
>
> this is the call for adoption of OAuth 2.0 Discovery, seehttps://tools.ietf.org/html/draft-jones-oauth-discovery-00
>
> Please let us know by Feb 2nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Note: If you already stated your opinion at the IETF meeting in Yokohama
> then you don't need to re-state your opinion, if you want.
>
> The feedback at the Yokohama IETF meeting was the following: 19 for /
> zero against / 4 persons need more information.
>
> Ciao
> Hannes & Derek
>
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>