Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Torsten Lodderstedt <torsten@lodderstedt.net> Mon, 02 March 2020 16:44 UTC

Return-Path: <torsten@lodderstedt.net>
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 404D83A0B52 for <oauth@ietfa.amsl.com>; Mon, 2 Mar 2020 08:44:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwdMuATS6SH4 for <oauth@ietfa.amsl.com>; Mon, 2 Mar 2020 08:44:02 -0800 (PST)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E762A3A093D for <oauth@ietf.org>; Mon, 2 Mar 2020 08:44:01 -0800 (PST)
Received: by mail-wr1-x42e.google.com with SMTP id j16so586917wrt.3 for <oauth@ietf.org>; Mon, 02 Mar 2020 08:44:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+okNt0djq55MaPHU02r5Jhc70B8LbG5igVlCLRVw0q8=; b=yD75LyWzKbGC2Sv/zkAQwsNlo/9+gPnIxBJb90PsD3+UNOpAgx7hscI0YUYkEnSX+N ppvknvas1ErNGNfu2QU6QdknhH9uQyfvZ7aVNUj6P5eg4MrJHqTBYxNSqXE8d5fb6JwK IfnylxptpM4FQDt5DTJy/GOHLwC+wBKnuPzc0TWfseDH2yHGV9fa4HhGUfAPbkUKh5Mn IFWHp5joN+rrKbGgFz3xQ/oK3T4PHhkEEnC1vlja5+RP/scdHPMOGN1UZwjEJn+3zES8 Po4sWypl/ZGae4CwNQ/YnIeCkQ/jKLuEgww8wEt0oW2rUgGbbaUIG7T3wL7WObNIjFpu xYBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+okNt0djq55MaPHU02r5Jhc70B8LbG5igVlCLRVw0q8=; b=Mt+puYqsYYb14gJYOOO25P2Xu1+XtDCi3zOdkMLQpsvVYqtA63VHSdUCnL2HYmtS1T eEfYUyp3Y3OBuBqcoaik6pHpxQQzw56fJ/Q5QkcZw6uBbnFi0mS7UU0XVtJYRLAINCm+ dyLY8YZkGVtKNkgBFkLIefBXUsvO2T6/vQCahBp3OkwFiTXN2EjtXgNpWPN0WWqaNKYx ozQqx6jsIbYYx4BFRuXDBwtWfBIbNrfwf0iwDEg7bD4NwaI+SQdr8txdLuiz/PapYITX IWHUR1XoeLT8zPtFlfzUJ/iy86ws1hgIFYyAuLroeWKlOX2WdLJh4HiVXLSU+dqHOL8Q N0zA==
X-Gm-Message-State: ANhLgQ1eayRXLtCPrYuQK38N7i4Apcfhb5uzd6Ohpo3YSjEPkIQ9GdFj opVWXau/MMj7xWaUI3MITsPp+156SqupWw==
X-Google-Smtp-Source: ADFU+vs2INsvTDHs7DtkwnjAEQjcn9Hy5V0kpQ0350H0psoh53pq96eYKtVb0/hpSgTJQXHbfsAnpw==
X-Received: by 2002:adf:f751:: with SMTP id z17mr461168wrp.207.1583167440216; Mon, 02 Mar 2020 08:44:00 -0800 (PST)
Received: from [10.226.254.230] (80-254-69-38.dynamic.monzoon.net. [80.254.69.38]) by smtp.gmail.com with ESMTPSA id q12sm30685497wrg.71.2020.03.02.08.43.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2020 08:43:59 -0800 (PST)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <13A6E943-3C58-4064-9DE4-AFB1F351BD47@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_217D78C4-663F-495B-A459-A5E6EA77B350"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Mon, 02 Mar 2020 17:43:57 +0100
In-Reply-To: <CAHdPCmO7nfG6jXgo56HdUmmz8iu0O-Dd-sPO3pc_-6MWCheOMQ@mail.gmail.com>
Cc: oauth <oauth@ietf.org>, Brian Campbell <bcampbell@pingidentity.com>
To: Takahiko Kawasaki <taka@authlete.com>
References: <CAHdPCmPCMJqH-aOC2SjFhGd9sjd01xw=VEj5y1jA5nRNRhu4EA@mail.gmail.com> <5514F7A5-D87D-42D8-9DA0-9ADCDD75D989@lodderstedt.net> <CAHdPCmO7nfG6jXgo56HdUmmz8iu0O-Dd-sPO3pc_-6MWCheOMQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/owCgOG8Hzsknu2Q1kzpSV9ToorE>
Subject: Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 02 Mar 2020 16:44:05 -0000

Hi Taka,

I see, the audience is multi value. In my impression both specs assume a single value audience. 

But I think we can handle this as follows: Since the caller of the introspection respect is a single RS, the AS first needs to map & check the resources associated with the underlying access token against that caller. The RS is authenticated at the introspection endpoint using a client_id (and some credential), so the AS needs to map the client_id to resource identifier. If the result is in the set of the resources associated with the underlying access token, the AS can create an Introspection Response, which only contains this particular resource. 

What do you think?

best regards,
Torsten. 

> On 2. Mar 2020, at 17:31, Takahiko Kawasaki <taka@authlete.com> wrote:
> 
> Hi Torsten,
> 
> For example, if an authorization request includes two "resource" request parameters like below,
> 
> resource=https://host1.example.com/resource1
> resource=https://host2.example.com/resource2
> 
> RFC 8707 expects that the value of "aud" in an introspection response look like the following.
> 
> "aud" : [
>   "https://host1.example.com/resource1",
>   "https://host2.example.com/resource2",
> ]
> 
> How does the implementation of the introspection endpoint insert the identifier of the resource server (the API caller?) into the "aud" array above? In other words, what is the expected resultant value of the "aud" array in this case?
> 
> Taka
> 
> 
> On Mon, Mar 2, 2020 at 10:54 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
> Hi Taka, 
> 
> > On 1. Mar 2020, at 08:10, Takahiko Kawasaki <taka@authlete.com> wrote:
> > 
> > Hello,
> > 
> > I'm wondering if the following conflicts in "JWT Response for OAuth Token Introspection" (draft 8) have already been pointed out.
> > 
> > RFC 8707 (Resource Indicators for OAuth 2.0) requires that 'aud' in an introspection response hold the values of the 'resource' request parameters, whereas "JWT Response for OAuth Token Introspection" says that 'aud' MUST identify the resource server receiving the token introspection response. The definitions conflict.
> 
> RFC 8707 states 
> 
> The authorization server may use
>    the exact "resource" value as the audience or it may map from that
>    value to a more general URI or abstract identifier for the given
>    resource.
> 
> draft-ietf-oauth-jwt-introspection-response-08 states
> 
> The value of the "aud" claims MUST identify the resource server
>    receiving the token introspection response.
> 
> So RFC 8707 gives choices of how the resource server might be identified and draft-ietf-oauth-jwt-introspection-response-08 says the AS must identify the RS without prescribing any particular way. So basically you can use the advice given by  RFC 8707 to implement the requirement stated by draft-ietf-oauth-jwt-introspection-response-08.
> 
> I don’t see a conflict. 
> 
> > 
> > RFC 7662 (OAuth 2.0 Token Introspection) requires that 'iat' in an introspection response indicate when the access/refresh token was issued, whereas "JWT Response for OAuth Token Introspection" says that 'iat' indicates when the introspection response in JWT format was issued. The definitions conflict.
> 
> I will come back to this issue in an answer to Filip’s post.
> 
> best regards,
> Torsten. 
> 
> > 
> > Best Regards,
> > Takahiko Kawasaki
> > Authlete, Inc.
> > 
> > 
> > 
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>