Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens

Torsten Lodderstedt <torsten@lodderstedt.net> Sun, 07 February 2021 21:58 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 D4A083A1395 for <oauth@ietfa.amsl.com>; Sun, 7 Feb 2021 13:58:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 tu-PX1BfBqPO for <oauth@ietfa.amsl.com>; Sun, 7 Feb 2021 13:58:24 -0800 (PST)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 E06E33A1392 for <oauth@ietf.org>; Sun, 7 Feb 2021 13:58:23 -0800 (PST)
Received: by mail-wr1-x42f.google.com with SMTP id u14so15034835wri.3 for <oauth@ietf.org>; Sun, 07 Feb 2021 13:58:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=mykHn/qZVVA22XA41UXf3ENNqNMSW5puxm+Nra+sLH0=; b=zx+iajtR1ueaTadllhRX/Nnln2dhUdMZ+Kh1n6XYVbxNrAzthWv4sMRhmA9w2u1wyI aZ2MkyaMRZ7K7UFIC4vzugZKKf+8xJdmQaRDvSlIqsYXsbBOjNGsktB69fezkWbH31J3 r0dg8wXy9WNfyLxhVevErVKctPD7azEtwpOodknZ6Eznkgiekb1zoX8zDYphjM0gxP/h tmLA71F5o3HNXOa9Fvz9FF/I1LfJ8SeP7+T6Q6j4sN9Y0nDHkRVC7/P7alQKrI4zzn9v fFB3CL6H4iB+JU3xp+k4rKC+uTUzHivih+6eYTmw4914z/PBlqmlxusMTfdkl0tT9EFe IpYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=mykHn/qZVVA22XA41UXf3ENNqNMSW5puxm+Nra+sLH0=; b=YtyDnVhy4fJRf0b80oCYSMTMtN6SNaTXJ0aUELZAEkgMi/8jK6P2UziCzstA1ovuW1 VQwUSYjHKL0tX5h1Mw4FVVkGFoGN3XHxcwo6hlo4Wj8VjjtmG4FO1QUuwcPX+BRnx5pQ KkpOaNof+ygMjK1T79e1CjHPjKDR9aeYr1cA6vff7+eNKiRKHWehdISM6hoNeT6GTVFo ODF5njCqSoxcUNXqGp/eMdDeRWx/0oXXQLF9YJJvFyEgQGC5H6CP6L3icP89vt5Gocum IfX6jf5gusuybYoO1v1spvDRFW69wWGm3cZFzzI+ZvUTNVVS9duujdb69JpZz6l9lfWg Tt1A==
X-Gm-Message-State: AOAM531zXDNvjfwhtrt8h4u1l1znQ7QzTNNTovKeVQvanaxbb9PLU+Ob SLVwyUVqWhBITO9GLxo2GfXw3Q==
X-Google-Smtp-Source: ABdhPJyyc2SVLrvJx8BYOlX6PK2BYEoNYsPx5nFzIDdDzG6bVy/9jpQ9GFX/iL9lXzDuzFMd7K/dkg==
X-Received: by 2002:a5d:4bc2:: with SMTP id l2mr17020760wrt.204.1612735102244; Sun, 07 Feb 2021 13:58:22 -0800 (PST)
Received: from [192.168.71.135] (p5b0d9c0a.dip0.t-ipconnect.de. [91.13.156.10]) by smtp.gmail.com with ESMTPSA id l2sm16979014wmq.17.2021.02.07.13.58.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Feb 2021 13:58:21 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail-263011FB-C9DB-41E6-9A81-05A2E7727655"; protocol="application/pkcs7-signature"; micalg="sha-256"
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Mime-Version: 1.0 (1.0)
Date: Sun, 07 Feb 2021 22:58:19 +0100
Message-Id: <536313C1-95E8-4A05-97B1-F3CD8984B49F@lodderstedt.net>
References: <CALkShcuu6dR2=SqAaVZTTm2zjqQPA4MtvswUQmn-2_vqE2w8Yg@mail.gmail.com>
Cc: oauth <oauth@ietf.org>, draft-ietf-oauth-jwt-introspection-response@ietf.org
In-Reply-To: <CALkShcuu6dR2=SqAaVZTTm2zjqQPA4MtvswUQmn-2_vqE2w8Yg@mail.gmail.com>
To: Andrii Deinega <andrii.deinega@gmail.com>
X-Mailer: iPad Mail (18B92)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/GWEkuItLC2V1hVXJ9FW7AOS6c58>
Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens
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: Sun, 07 Feb 2021 21:58:26 -0000

Hi Andrii,

> Am 07.02.2021 um 21:30 schrieb Andrii Deinega <andrii.deinega@gmail.com>:
> 
> 
> Hi Torsten,
> 
> thank you for your response.
> 
> My use case is pretty straight forward
> 
> An OAuth client queries the AS to determine the active state of an access token and gets the introspection response which indicates that this access token is active (using RFC7662).
> 
> An OAuth client queries the AS to determine the active state of a refresh token and gets the introspection response which indicates that this refresh token is active (using RFC7662).
> 
> An OAuth client queries the AS to determine the active state of an access token and gets the introspection response (JWT) which indicates that this access token is active (using this draft).
> 
> Now, an OAuth client queries the AS to determine the active state of a refresh token (using this draft)... How will the introspection response look like assuming that the client provides the valid refresh token and technically, nothing stops it from doing so.

why should the state be provided as JWT?I think the plain JSON response is sufficient in that case.  I also think using token introspection for checking the state of a token from the client side has limited utility. The definitive decision is always made when the client tries to access a resource. 

I‘m therefore leaning towards explicitly stating in our draft that it is not intended to be used with refresh tokens.

best regards,
Torsten.

> 
> Regards,
> Andrii
> 
> 
>> On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>> Hi Andrii,
>> 
>> thanks for your post. 
>> 
>> The draft is intended to provide AS and RS with a solution to exchange signed (and optionally encrypted) token introspection responses in order to provide stronger assurance among those parties. This is important in use cases where the RS acts upon the introspection response data and wants the AS to take liability re the data quality. 
>> 
>> I’m not sure whether there are similar use cases if a client introspects a refresh token. What is your use case?
>> 
>> best regards,
>> Torsten.  
>> 
>> > Am 07.02.2021 um 08:41 schrieb Andrii Deinega <andrii.deinega@gmail.com>:
>> > 
>> > Hi WG,
>> > 
>> > draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth 2.0 Token Introspection [RFC7662] specifies a method for a protected resource to query an OAuth 2.0 authorization server to determine the state of an access token and obtain data associated with the access token." which is true. Although, according to RFC7662, the introspection endpoint allows to introspect a refresh token as well. Hence, the question I have is how will a token introspection response look like when the caller provides a refresh token and sets the "Accept" HTTP header to "application/token-introspection+jwt"?
>> > 
>> > I expect there will be no differences, right?
>> > 
>> > If so, I suggest to
>> >       • replace "a resource server" by "the caller" in section 4 (Requesting a JWT Response)
>> >       • change "If the access token is invalid, expired, revoked" by "If a given token is invalid, expired, revoked" in section 5 (JWT Response)
>> > If not, my suggestion would be to clarify what the AS should do when it asked to introspect the refresh token in general and additionally, what should happen in the same case based on the type of the caller from the AS's point of view.
>> > 
>> > Regards,
>> > Andrii
>> > 
>>