Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt

"Richer, Justin P." <> Wed, 09 January 2013 20:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 07D3A21F88B4 for <>; Wed, 9 Jan 2013 12:15:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.186
X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WvyNZJptrG84 for <>; Wed, 9 Jan 2013 12:15:11 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0148721F88AE for <>; Wed, 9 Jan 2013 12:15:11 -0800 (PST)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 8F08D1F2977; Wed, 9 Jan 2013 15:15:10 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG ( []) by (Postfix) with ESMTP id 680261F2955; Wed, 9 Jan 2013 15:15:10 -0500 (EST)
Received: from IMCMBX01.MITRE.ORG ([]) by IMCCAS04.MITRE.ORG ([]) with mapi id 14.02.0318.004; Wed, 9 Jan 2013 15:15:10 -0500
From: "Richer, Justin P." <>
To: Torsten Lodderstedt <>
Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt
Thread-Index: AQHN7fJSaTtsJD7Erk6+DEfqvZzSmJhBYZUGgAAMCbeAAFZagA==
Date: Wed, 09 Jan 2013 20:15:08 +0000
Message-ID: <B33BFB58CCC8BE4998958016839DE27E06873FA8@IMCMBX01.MITRE.ORG>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E06873FA8IMCMBX01MITREOR_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Jan 2013 20:15:13 -0000

On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt <<>> wrote:

Hi Justin,

Am 09.01.2013 um 20:35 schrieb Justin Richer <<>>:

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.

You are making an interesting point here. To differentiate the resource server and the permissions of a particular at this server makes a lot of sense. BUT: the authorization request does not allow the client to specify both in separate parameters. Instead both must be folded into a single "scope" parameter. If I got your example correctly, the scope of the request would be


whereas the results of the introspection would be


It's probably the different semantics of scope that confused me.

No, sorry if I was unclear: scope is scope, no different semantics. In this example case, you'd ask for scope=myserver:read and get back scope=myserver:read. I'm not suggesting that these be split up. Since the AS in this case knows that there's an audience, so it can return audience=myserver as well. The fact that it knows this through the scope mechanism is entirely system-dependent.

I agree that the lack of a method for specifying audience does make returning this field a little odd for simple OAuth deployments, but since audience restriction is a big part of clustered and enterprise deployments (in my personal experience), then it's something very useful to have the server return.

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.

I probably didn't describe well what I meant. I would suggest to return a JWT claim set from the introspection endpoint. That way one could use the same claims (e.g. iat instead of issued_at) for structured and handle-based tokens. So the logic operating on the token data could be the same.

OK, I follow you now. I'd be fine with re-using the JWT claim names and extending the namespace with the OAuth-specific parameters, like scope, that make sense here.

 -- Justin


 -- Justin

Am 09.01.2013 um 20:10 schrieb Justin Richer <<>>:

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:   <><>
To:     <><>

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

   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<>