Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item
George Fletcher <gffletch@aol.com> Wed, 30 July 2014 13:29 UTC
Return-Path: <gffletch@aol.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 DE6CA1A006C for <oauth@ietfa.amsl.com>; Wed, 30 Jul 2014 06:29:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 Y1Kl1-PMaS8e for <oauth@ietfa.amsl.com>; Wed, 30 Jul 2014 06:29:47 -0700 (PDT)
Received: from omr-m05.mx.aol.com (omr-m05.mx.aol.com [64.12.143.79]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AC511A0030 for <oauth@ietf.org>; Wed, 30 Jul 2014 06:29:46 -0700 (PDT)
Received: from mtaout-aam02.mx.aol.com (mtaout-aam02.mx.aol.com [172.27.19.146]) by omr-m05.mx.aol.com (Outbound Mail Relay) with ESMTP id 7B144700000A9; Wed, 30 Jul 2014 09:29:45 -0400 (EDT)
Received: from [10.181.176.18] (unknown [10.181.176.18]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aam02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 1C00638000087; Wed, 30 Jul 2014 09:29:45 -0400 (EDT)
Message-ID: <53D8F348.4000002@aol.com>
Date: Wed, 30 Jul 2014 09:29:44 -0400
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Phil Hunt <phil.hunt@oracle.com>
References: <53D6895F.4050104@gmx.net> <CAEayHEM+pqDqv1qx=Z-qhNuYM-s2cV0z=sQb_FAJaGwcLpq_rQ@mail.gmail.com> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <3A57B125-504B-4427-930A-75F0D58AF26C@oracle.com>
In-Reply-To: <3A57B125-504B-4427-930A-75F0D58AF26C@oracle.com>
Content-Type: multipart/alternative; boundary="------------020207070301010706030907"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1406726985; bh=I0iV88QQ6u/r+PATU9qufQJ4WLO/59dbJhupajKRTOU=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=pnVa0HkikbhqMKTi9cRGSD8132egJ6dneMH8UOTHN0bqoEqIUxboRhVr4yNghfYm3 p6o57UbxKXelTrHPR5VdlR7N+JQWxeKlHjg44CEQu4xrWXkHornryjFmarV3iQQjw4 9W6vBDkrFd1O65hxuXYvI+dfehYR2M9vDuJ6MQHU=
x-aol-sid: 3039ac1b139253d8f349260a
X-AOL-IP: 10.181.176.18
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/HyqbbHBPFCZy_NdvFs3OMubezJM
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item
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: <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: Wed, 30 Jul 2014 13:29:50 -0000
Actually, I view this in a much simpler way. In today's environment there is a tight coupling between AS and RS. Each deployment has to develop it's own mechanism for dealing with understanding tokens (even if the AS and RS are in the same domain). The introspection spec solve probably 80+ percent of those tight coupling use cases. As an RS, I do not want to have to write special code for every AS to understand their unique token or mechanism for validating tokens and I'm sure that every AS does not want to implement our specific token. In both of these cases there is a tight coupling required. As for the privacy issues, the introspection endpoint is an OAuth2 protected API and can enforce the presentation of an authorization token (RFC 6750) before responding with the token data. This allows for the return of pseudonymous identifiers and other privacy protecting mechanisms. Thanks, George // Line feeds added for formatting purposes only :) { "bit_of_a_rant" : "Since the introspection spec is not mandatory to implement, I don't see why there is such concern over it. If an AS doesn't want to implement the endpoint, they don't need to. However, for those who do (and there is a good number in this community) it solves a real problem." } On 7/29/14, 7:44 PM, Phil Hunt wrote: > Thanks everyone for the comments. > > It sounds like we have multiple dimensions to introspection features > and requirements: > > * there are UMA cases, > * corporate third-party AS-RS relationships (e.g. the RS chooses a > third-party AS), > * multi-vendor cases, > * tooling/library cases, > > There’s also federation cases. Federated authorization seems like a > different problem than federated authentication from a trust perspective. > > Another dimension to this is methodology: > 1. Lookup by token / token id / reference > 2. Query by token / token id / reference > 3. Passing standardized information in a standardized token format or > token URI. > > There may be some complex privacy issues involved as well. For > example, in many cases, the desire is to allow authz information > *only* the actual content owner / delegator may be intentionally > pseudonymous. > > _I would support first developing a use case document to figure out if > there is an appropriate pattern that can satisfy (and simplify) a > majority of cases._ > > Phil > > @independentid > www.independentid.com <http://www.independentid.com> > phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> > > > > On Jul 29, 2014, at 3:24 PM, George Fletcher <gffletch@aol.com > <mailto:gffletch@aol.com>> wrote: > >> We also have a use case where the AS is provided by a partner and the >> RS is provided by AOL. Being able to have a standardized way of >> validating and getting data about the token from the AS would make >> our implementation much simpler as we can use the same mechanism for >> all Authorization Servers and not have to implement one off solutions >> for each AS. >> >> Thanks, >> George >> >> On 7/28/14, 8:11 PM, Phil Hunt wrote: >>> Could we have some discussion on the interop cases? >>> >>> Is it driven by scenarios where AS and resource are separate >>> domains? Or may this be only of interest to specific protocols like UMA? >>> >>> From a technique principle, the draft is important and sound. I am >>> just not there yet on the reasons for an interoperable standard. >>> >>> Phil >>> >>> On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com >>> <mailto:t.broyer@gmail.com>> wrote: >>> >>>> Yes. This spec is of special interest to the platform we're >>>> building for http://www.oasis-eu.org/ >>>> >>>> >>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig >>>> <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote: >>>> >>>> Hi all, >>>> >>>> during the IETF #90 OAuth WG meeting, there was strong consensus in >>>> adopting the "OAuth Token Introspection" >>>> (draft-richer-oauth-introspection-06.txt) specification as an >>>> OAuth WG >>>> work item. >>>> >>>> We would now like to verify the outcome of this call for >>>> adoption on the >>>> OAuth WG mailing list. Here is the link to the document: >>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ >>>> >>>> If you did not hum at the IETF 90 OAuth WG meeting, and have an >>>> opinion >>>> as to the suitability of adopting this document as a WG work item, >>>> please send mail to the OAuth WG list indicating your opinion >>>> (Yes/No). >>>> >>>> The confirmation call for adoption will last until August 10, >>>> 2014. If >>>> you have issues/edits/comments on the document, please send these >>>> comments along to the list in your response to this Call for >>>> Adoption. >>>> >>>> Ciao >>>> Hannes & Derek >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> -- >>>> Thomas Broyer >>>> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >
- [OAUTH-WG] Confirmation: Call for Adoption of "OA… Hannes Tschofenig
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Eve Maler
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Bill Mills
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Thomas Broyer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Phil Hunt
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Justin Richer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Phil Hunt
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Thomas Broyer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Justin Richer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Tirumaleswar Reddy (tireddy)
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Mark Dobrinic
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Paul Madsen
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Mike Jones
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Justin Richer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Bill Mills
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Justin Richer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Eve Maler
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Phil Hunt
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Thomas Broyer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… George Fletcher
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Phil Hunt
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Mike Jones
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Thomas Broyer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Mike Jones
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Justin Richer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Justin Richer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Phil Hunt
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Thomas Broyer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Phil Hunt
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Justin Richer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Anthony Nadalin
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Phil Hunt
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Eve Maler
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Tirumaleswar Reddy (tireddy)
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Thomas Broyer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Sergey Beryozkin
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Sergey Beryozkin
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… John Bradley
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Sergey Beryozkin
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… John Bradley
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Sergey Beryozkin
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… George Fletcher
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… George Fletcher
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… George Fletcher
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… John Bradley
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Anthony Nadalin
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… John Bradley
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Brian Campbell