Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04

Thomas Broyer <> Fri, 25 October 2013 09:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C696A11E8392 for <>; Fri, 25 Oct 2013 02:20:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lD+TwpM1ifFb for <>; Fri, 25 Oct 2013 02:20:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c02::233]) by (Postfix) with ESMTP id 0AD8D11E839E for <>; Fri, 25 Oct 2013 02:20:17 -0700 (PDT)
Received: by with SMTP id x16so2512442vbf.38 for <>; Fri, 25 Oct 2013 02:20:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YFePt1PMDh56pY/8WHEdC4ICbNaua3qaduG7FOZSO8U=; b=DUTYR6Lir6F1qRSn39oHUBVXZ0WfWxPmMKgd3yodXU1GAY2O/+15SRQwfbAFN9HjjQ mC4AXWJqWA0KV5jBsltl+rRD7khjSUqQ78wC7R01QvYUD+TleM/+zWpAWScOANrDJID4 EYAzuazVS2AOSOBtJeC18CBczd78fCJJxfmLVd/He8+FoA+FjsqYAdzTYX4jlDMMDHNo Z4H6JhvfL7l62m68RKvEuzycZyTJ5bxV1sD2ESlppxVEySsROnSKxpgchSxm9q45ZObP lRisivy+PeK+hjdhDwfVSm8tlse9Rq+Yh6zyHHSSHDBpVfeNuieAk4BGsI+Z4kTkANym M6Bg==
X-Received: by with SMTP id tv2mr3922893vec.11.1382692810507; Fri, 25 Oct 2013 02:20:10 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 25 Oct 2013 02:19:50 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Thomas Broyer <>
Date: Fri, 25 Oct 2013 11:19:50 +0200
Message-ID: <>
To: Torsten Lodderstedt <>
Content-Type: multipart/alternative; boundary=089e0115ef9ccdd0e704e98d411f
Cc: "<>" <>
Subject: Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04
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: Fri, 25 Oct 2013 09:20:25 -0000

On Thu, Oct 24, 2013 at 7:50 AM, Torsten Lodderstedt <> wrote:

> Hi Thomas,
> we generate access tokens per resource server in order to mitigate this
> and other risks. You must issue those tokens to different audiences
> (resource server id) and the resource servers must validate if the token is
> issued for its particular audience. Otherwise a compromised resource server
> can still abuse the tokens.
> Talking about burden: You need to compare the effort needed to obtain
> different access tokens to the effort needed to implement proof of
> possession.

On our backlog is also support for "service accounts" (to use Google's
terminology), so clients will likely need to do some crypto-related work.
Asking them to do it for each and every request to sign the access token
might not be that much of a problem (if they have the right tools;
google-oauth-java-client for instance does a great job making all of this
easier, and google-api-java-client adds service accounts support with a
just-as-easy-to-use API:;
same for PHP, Python, etc.)
That said, I'm rather new to crypto too, so I might be oversimplifying
I'll check with the project manager and project owner which approach we'd
use (we could also support both…)

I recommend you to take a look into the OAuth threat model for a discussion
> of this threat (

Thanks for the pointer. I had already read that RFC but somehow forgot
about some details, and failed to check it back for that particular problem.

Thomas Broyer
/tɔ.ma.bʁ <>