Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt
Justin Richer <jricher@mitre.org> Wed, 09 January 2013 19:35 UTC
Return-Path: <jricher@mitre.org>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FEF21F8581 for <oauth@ietfa.amsl.com>; Wed, 9 Jan 2013 11:35:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.891
X-Spam-Level:
X-Spam-Status: No, score=-5.891 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csExr5Z6-ppm for <oauth@ietfa.amsl.com>; Wed, 9 Jan 2013 11:35:06 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3566C21F8534 for <oauth@ietf.org>; Wed, 9 Jan 2013 11:35:06 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 897D01F28CB; Wed, 9 Jan 2013 14:35:05 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6AC061F02FC; Wed, 9 Jan 2013 14:35:05 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 9 Jan 2013 14:35:05 -0500
Message-ID: <50EDC666.6040808@mitre.org>
Date: Wed, 09 Jan 2013 14:35:02 -0500
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Torsten Lodderstedt <torsten@lodderstedt.net>
References: <20130108224847.20224.42156.idtracker@ietfa.amsl.com> <50EDC0AE.6050005@mitre.org> <C3C21E32-8A85-4AC8-973E-4FCD25D61791@lodderstedt.net>
In-Reply-To: <C3C21E32-8A85-4AC8-973E-4FCD25D61791@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------000403030505080305090003"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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, 09 Jan 2013 19:35:07 -0000
Thanks for the review, answers inline: > why is there a need for both scope and audience? I would assume the > scope of the authorization request is typically turned into an > audience of an access token. You can have an audience of a single server that has multiple scopes, or a single scope that's across multiple servers. Scope is an explicit construct in OAuth2, and while it is sometimes used for audience restriction purposes, they really are independent. Note that both of these are optional in the response -- if the AS has no notion of audience restriction in its stored token metadata, then it just doesn't return the "audience" field. > > Generally, wouldn't it be simpler (spec-wise) to just return a JWT > instead of inventing another set of JSON elements? What would be the utility in returning a JWT? The RS/client making the call isn't going to take these results and present them elsewhere, so I don't want to give the impression that it's a token. (This, incidentally, is one of the main problems I have with the Ping introspection approach, which uses the Token Endpoint and invents a "token type" as its return value.) Also, the resource server would have to parse the JWT instead of raw JSON, the latter of which is easier and far more common. Besides, I'd have to invent new claims for things like "valid" and "scopes" and what not, so I'd be extending JWT anyway. So while I think it's far preferable to use an actual JSON object, I'd be fine with re-using JWT claim names in the response if people prefer that. I tried to just use the expanded text since size constraints are not an issue outside of a JWT, so "issued_at" instead of "iat". Finally, note that this is *not* the same as the old OIDC CheckId endpoint which merely parsed and unwrapped the data inside the token itself. This mechanism works just as well with an unstructured token as input since the AS can store all of the token's metadata, like expiration, separately and use the token's value as a lookup key. -- Justin > Am 09.01.2013 um 20:10 schrieb Justin Richer <jricher@mitre.org > <mailto:jricher@mitre.org>>: > >> Updated the introspection draft with feedback from the UMA WG, who >> have incorporated it into their latest revision of UMA. >> >> I would like this document to become a working group item. >> >> -- Justin >> >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-richer-oauth-introspection-01.txt >> Date: Tue, 8 Jan 2013 14:48:47 -0800 >> From: <internet-drafts@ietf.org> >> To: <jricher@mitre.org> >> >> >> >> A new version of I-D, draft-richer-oauth-introspection-01.txt >> has been successfully submitted by Justin Richer and posted to the >> IETF repository. >> >> Filename: draft-richer-oauth-introspection >> Revision: 01 >> Title: OAuth Token Introspection >> Creation date: 2013-01-08 >> WG ID: Individual Submission >> Number of pages: 6 >> URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt >> Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection >> Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-01 >> Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01 >> >> Abstract: >> This specification defines a method for a client or protected >> resource to query an OAuth authorization server to determine meta- >> information about an OAuth token. >> >> >> >> >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] Fwd: New Version Notification for draf… Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Torsten Lodderstedt
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Torsten Lodderstedt
- Re: [OAUTH-WG] Fwd: New Version Notification for … Richer, Justin P.
- Re: [OAUTH-WG] Fwd: New Version Notification for … George Fletcher
- Re: [OAUTH-WG] Fwd: New Version Notification for … Sergey Beryozkin
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … George Fletcher
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … George Fletcher
- Re: [OAUTH-WG] Fwd: New Version Notification for … Igor Faynberg
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … George Fletcher
- Re: [OAUTH-WG] Fwd: New Version Notification for … Richer, Justin P.
- Re: [OAUTH-WG] Fwd: New Version Notification for … George Fletcher