Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

Thomas Broyer <> Tue, 29 July 2014 21:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 25EB81A0171 for <>; Tue, 29 Jul 2014 14:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UcdNd9O04RoY for <>; Tue, 29 Jul 2014 14:31:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AAFFD1A010C for <>; Tue, 29 Jul 2014 14:31:43 -0700 (PDT)
Received: by with SMTP id l4so209622lbv.30 for <>; Tue, 29 Jul 2014 14:31:41 -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=OC4xtV3VSlnL+Suz/yu5/y0//hnnh/GbfuT0CvEow5Y=; b=w4ceBgfBjQ02JJ0XJbi1dvdRql3l9gauxpK1LJFxK23HrZIiCEei//aoZ3cav1L8sH ZupRxI45315b//t/LF71od2/FVepVXqJZ7mexSWrGNInDlKCH1xj+91TxoZyHrL0Frxw fVqdfVE79+FRUe4j6pVmGuZ8RQZyv0e6Da7c6iXVYd2tZtEnF5K6gRsvLwNvKLhN2Rlb 2on0cb24I4yYghpp5U9/IrZ1V5FdK6oUJJTb3Xnb/gVhuKDNCuNTGWr43pqzYOMF9uO0 LQBkJrME3M/0xftAjXC+4pL/6bIspdFW1DF9a3C2C5KDIXrUdhbyHrTEWr5ybfHDxnL0 pHXA==
X-Received: by with SMTP id v5mr5285479lag.84.1406669501897; Tue, 29 Jul 2014 14:31:41 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 29 Jul 2014 14:31:21 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Thomas Broyer <>
Date: Tue, 29 Jul 2014 23:31:21 +0200
Message-ID: <>
To: Phil Hunt <>
Content-Type: multipart/alternative; boundary="089e0160acaefa211404ff5bc3cb"
Cc: "" <>
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item
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: Tue, 29 Jul 2014 21:31:46 -0000

On Tue, Jul 29, 2014 at 10:41 PM, Phil Hunt <> wrote:

> Making everything optional achieves no benefits, you just end up with a
> complex set of options and no inter op.
> We had the same issue with dyn reg.
> I prefer to first get agreement on use case.
> What are the questions a caller can ask and what form of responses are
> available.
> Should this be limited to authz info or is this a back door for user data
> and wbfinger data?
> I would prefer to have agreement on use cases before picking a solution
> right now.

The use-case (in our case) is driving authorization at an RS from a
different vendor than the AS (we have a single AS, and everyone is free to
register a RS in the AS catalog), as explained by Justin 3 hours ago.

If the response is {"active":false}, the RS is supposed to reply with a 401
and invalid_token. This could happen if the token is invalid/unknown to the
AS, expired, or does not grant any scope registered by the calling
RS (identified by HTTP Basic auth –Client Authentication– at the endpoint).
Our "active":true responses include the "scope" claim filtered to only
include the scopes registered by the calling RS, so it can possibly return
a 403 with insufficient_scope.
They also include the "sub" claim and a custom "sub_groups" claim so the RS
can drive authorization depending on the user. Our "sub_groups" claim
includes identifiers for groups the user is a member of (so that you could
control access by groups rather than only a list of users).
Finally, we also send the "client_id" claim so the RS could identify who
uses its data, and possibly charge them accordingly (or refuse them access
if they need prior, out-of-band, approval, or they've been blacklisted,
etc.), and the "iat" and "exp" claims so they could possibly refuse access
if the token is not recent enough or will expire too soon.

In due course, we'll probably add "amr" and/or "acr" claims (or similar)
because some processes (in France for example) require the use of client
certificates, etc.

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