Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

Justin Richer <> Wed, 03 December 2014 01:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2A6821A1BD7 for <>; Tue, 2 Dec 2014 17:37:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.71
X-Spam-Status: No, score=-3.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URI_NOVOWEL=0.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vocEb3opkMNb for <>; Tue, 2 Dec 2014 17:37:09 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 171851A1AEB for <>; Tue, 2 Dec 2014 17:37:06 -0800 (PST)
X-AuditID: 1209190e-f799e6d000000cfe-a7-547e6941f79c
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id FF.28.03326.1496E745; Tue, 2 Dec 2014 20:37:05 -0500 (EST)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id sB31b44w023512; Tue, 2 Dec 2014 20:37:05 -0500
Received: from [IPv6:2607:fb90:2402:7470:0:44:6067:c801] ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id sB31b0c2006326 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 2 Dec 2014 20:37:01 -0500
Date: Tue, 02 Dec 2014 20:36:59 -0500
Message-ID: <>
Importance: normal
From: Justin Richer <>
To: Phil Hunt <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=""
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrOuYWRdisP+JssXJt6/YLBbMb2R3 YPJYsuQnk8fHp7dYApiiuGxSUnMyy1KL9O0SuDJ+7ZzBUrBgOkvFu72n2RsYV3SydDFycEgI mEj8ma7TxcgJZIpJXLi3ng3EFhJYzCRxbFd5FyMXkL2BUaKlaRsrhHOBSWLrg83sIFUsAqoS 847fA7OFBZwlbsw8wwJi8wq4SVy9fJEZZAGngJBE1y4JkDAbUPn0NS1MILaIgIrEt6vXGUFs ZqD4lwXvmSBaBSVOznzCAhEPldj24y7zBEa+WUhSs5CkIGx1iT/zLkHZihJTuh+yzwLazCyg JrGsVQlZeAEj2ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdY73czBK91JTSTYzg8JXk28H49aDS IUYBDkYlHl6LuLoQIdbEsuLK3EOMkhxMSqK8P5OBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4 s5OAcrwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKErwV6UCNgkWp6akV aZk5JQhpJg5OkOE8QMOPpYEMLy5IzC3OTIfIn2JUlBLnTQdpFgBJZJTmwfXC0ssrRnGgV4R5 T4JU8QBTE1z3K6DBTECDzzbUggwuSURISTUwtjOcilQ95ju5J+5t0eGLM97qZDrGWF7XEZJX WFJ0ds10tWCWBXb+HDGrJYyuCpw9Yqv+0XaS4t2mrLZKP2Hm2dOZnnBwf5HJvPj5RcnG2V67 /fc903dvFP7zZk3pSc6fq34Ed/xlCUxl/3J2v9ffoNcvv2+L3/rhOf8HttKnfP4bZX3Wssfu U2Ipzkg01GIuKk4EAAsPlQIKAwAA
Cc: "" <>
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Dec 2014 01:37:14 -0000

Ah, I think I got my threads crossed. Then yes, I agree with you, and I'm going to be making authorization a MUST instead of a SHOULD. Would love to hear feedback from other implementers on this point. 

-- Justin

/ Sent from my phone /

-------- Original message --------
From: Phil Hunt <> 
Date:12/02/2014  8:25 PM  (GMT-05:00) 
To: Justin Richer <> 
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 

I was asking in the context of the thread where the comment was made that you only need to authenticate if more information is provided.

This didn’t make sense to me. Because you would never make the call to re-confirm (pointless). Even a caller re-confirming is actually checking for more information - to see if the assertion has been revoked.



On Dec 2, 2014, at 5:04 PM, Justin Richer <> wrote:

Nothing says you need to pack the same information inside the JWT that you return from introspection. In our specific case, we don't put scopes or client IDs inside the JWT, just basic signature/identifier type stuff, so you need to call introspection to get back this other information. But the information inside the JWT includes an "iss" claim which the client can use to figure out *which* introspection endpoint to call.

This is just one of many different ways you could handle multiple AS at a single resource, and so it's definitely orthogonal to the basic introspection concept.

 -- Justin

On 12/2/2014 6:38 PM, Phil Hunt wrote:
I am confused. Why would you call the introspection endpoint if you were not expecting new information to be disclosed?


On Dec 2, 2014, at 14:26, Richer, Justin P. <> wrote:

I agree that there's some use in this (and in fact I've deployed a version that uses a signed JWT to indicate its authorization server), but it should remain outside the scope of this spec. It's a service discovery problem, it's orthogonal.

 -- Justin

On Dec 2, 2014, at 5:13 PM, John Bradley <> wrote:

Yes, but unless there is something new the introspection endpoint in UMA is tied to the resource.

In some cases having the token indicate the introspection endpoint may be useful.

John B.

Sent from my iPhone

On Dec 2, 2014, at 10:02 PM, Eve Maler <> wrote:

FWIW, UMA goes ahead and standardizes a good deal about the trust establishment between the RS and the AS, and (of course) profiles and wraps the token introspection spec as part of the resulting “authorization API” that the AS presents to the RS. A big part of the motivation for this is to support an n:n relationship between AS and RS entities.


On 2 Dec 2014, at 12:14 PM, John Bradley <> wrote:

Many of the proprietary introspection protocols in use return scope, role or other meta data for the RS to make its access policy decision on.
One of the reasons for using opaque tokens rather than JWT is to prevent leakage of that info.

Making authentication to the introspection endpoint a MUST if additional attributes are present is OK, I might even be inclined to say that authentication of some sort is always required, but that might be going a bit far for some use cases.

We have a lot of proprietary ways to do this from IBM, Layer 7, Ping etc. It would be nice if we could standardize it. Precluding other attributes would not be helpful for adoption.

One issue that we haven’t addressed in this spec is what happens if there are multiple AS for the RS and how it would decide what introspection endpoint to use.
Perhaps that needs to be a extension, leaving this for the simple case.

However having more than on e AS per RS is not as unusual as it once was in larger environments.

John B.

On Dec 2, 2014, at 4:56 PM, Richer, Justin P. <> wrote:

Agreed, which is why we've got space for the "sub" and "user_id" fields but not anything else about the user, and we've got a privacy considerations section for dealing with that. If you can help make the wording on that section stronger, I'd appreciate it.

 -- Justin

On Dec 2, 2014, at 2:25 PM, Bill Mills <> wrote:

If introspection returns any other user data beyond what is strictly required to validate the token based solely on possession of the public part it would be a mistake.

On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." <> wrote:

That's all fine -- it's all going over TLS anyway (RS->AS) just like the original token fetch by the client (C->AS). Doesn't mean you need TLS *into* the RS (C->RS) with a good PoP token.

Can you explain how this is related to "act on behalf of"? I don't see any connection.

 -- Justin

On Dec 2, 2014, at 2:09 PM, Bill Mills <> wrote:

Fetching the public key for a token might be fine, but what if the introspection endpoint returns the symmetric key? Data about the user? Where does this blur the line between this and "act on behalf of"?

On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." <> wrote:

The call to introspection has a TLS requirement, but the call to the RS wouldn't necessarily have that requirement. The signature and the token identifier are two different things. The identifier doesn't do an attacker any good on its own without the verifiable signature that's associated with it and the request. What I'm saying is that you introspect the identifier and get back something that lets you, the RS, check the signature.

 -- Justin

On Dec 2, 2014, at 1:40 PM, Bill Mills <> wrote:

"However, I think it's very clear how PoP tokens would work. ..."

I don't know if that's true. POP tokens (as yet to be fully defined) would then also have a TLS or transport security requirement unless there is token introspection client auth in play I think. Otherwise I can as an attacker take that toklen and get info about it that might be useful, and I don't think that's what we want.


OAuth mailing list

OAuth mailing list

Eve Maler
+1 425 345 6756

OAuth mailing list

OAuth mailing list