From nobody Sun Feb 7 12:30:26 2021 Return-Path: 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 3C7DE3A12C9; Sun, 7 Feb 2021 12:30: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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=gmail.com 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 TyIg2PAG8fK1; Sun, 7 Feb 2021 12:30:23 -0800 (PST) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 2BD603A12C8; Sun, 7 Feb 2021 12:30:23 -0800 (PST) Received: by mail-ej1-x629.google.com with SMTP id a9so21472629ejr.2; Sun, 07 Feb 2021 12:30:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TmopxuEjNCoTJ0KIiY+osSdbtXDTqLPRyiSQRTXQc78=; b=Lsjw4X8KrtL50Ci7VZ3MCMdSWhRjNF3JZCgLYPl2rgh4lfl1pjCXWhPsmEvBomwnId FFTVhyQ7BqodHOfVAWN9qt3ugS0L5K1c8wy94a81WMSlgMrtEbIfPZHY5sDYI519euYv V7EGQg7Zs5BLSAbpXRF5W54klhF5pvas0lGJlDkX/EpRQThLJeZMbLRd3dptZKoMJDIY rhE1EHOsBT2oncE+zxF16Ugs3VDI92g4FODzYJEqH0e9g6tZfonLwclats9JhHIv/Flz mCT+WZlVXL6AwmhlPGvqYY6oL+odIHytIuco2Ya5MBUFBH6mECPg474uKgrUGwFqlisz 5TKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TmopxuEjNCoTJ0KIiY+osSdbtXDTqLPRyiSQRTXQc78=; b=HStec2chSomHcrLHvF8ko9tFV6TeAlyrkbFX6ktDwqgdvsTicHIIZNwxvz9RffVlXu ls3pVZlZxbpTpzmFw7I9BOi4UT71jEqjYJeoXhgrnlzk6s/+N6ubtW8asptod2Jz2f0K U+jRjoEodeVKh/1rPxQM2ny8y/Wx1bBDflUtBKEoN+CZds1FHdnGFfylOMWgGkngzOy+ LDpQat9rY6r7mRGEqz0n9T8GOmGz8PSO6h17C8asJlHEINz7Z/WfPqfQP8l8C6U7tSTv UI5rBrCTtHjY+VJ/B5c759kVmAPPI2DCXJLv32yjXAI36keI8hbBB8Yyk/FKUitgRe1N E1nA== X-Gm-Message-State: AOAM532cYI+1ROOslcRzTh7THoe0CGGgy7ICABRde15BGDtoRe35xWRr ShAy+zMK9iyAxRtwfn5HL99smN853ck2k2Ri5Hk= X-Google-Smtp-Source: ABdhPJzZ03Zm1zwJ09DNgo8Sm7EWIr7m2PwSpIbOQHlVzUJ0KIvA3xmScte4Jk0p8WLcIYzmugiIfBt/Ikk/gdfH8S0= X-Received: by 2002:a17:906:af41:: with SMTP id ly1mr13526993ejb.525.1612729821405; Sun, 07 Feb 2021 12:30:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andrii Deinega Date: Sun, 7 Feb 2021 12:30:10 -0800 Message-ID: To: Torsten Lodderstedt Cc: oauth , draft-ietf-oauth-jwt-introspection-response@ietf.org Content-Type: multipart/alternative; boundary="0000000000001fa69c05bac4ec58" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 20:30:25 -0000 --0000000000001fa69c05bac4ec58 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. Regards, Andrii On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt 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 th= e > AS to take liability re the data quality. > > I=E2=80=99m not sure whether there are similar use cases if a client intr= ospects a > refresh token. What is your use case? > > best regards, > Torsten. > > > Am 07.02.2021 um 08:41 schrieb Andrii Deinega >: > > > > 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 t= o > introspect a refresh token as well. Hence, the question I have is how wil= l > a token introspection response look like when the caller provides a refre= sh > 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 > > =E2=80=A2 replace "a resource server" by "the caller" in section = 4 > (Requesting a JWT Response) > > =E2=80=A2 change "If the access token is invalid, expired, revoke= d" 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 > > > > --0000000000001fa69c05bac4ec58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Torsten,

thank you for your respons= e.

My use case is pretty straight=C2=A0forward

An OAuth client queries = the AS to determine the active state of an access token and gets the intros= pection response which indicates that this access token is active (using RF= C7662).

An OAuth client queries the AS to determine the active state of a refr= esh token and gets the introspection response which indicates that this ref= resh token is active (using RFC7662).

An OAuth client queries the AS to determ= ine the active state of an access token and gets the introspection response= (JWT) whi= ch indicates that this access token is active (using this draft).

No= w, an OAuth client queries the AS to determine the active state of a refresh token (u= sing this draft)... How will the introspection response look like assuming = that the client provides the valid refresh token and technically, nothing s= tops it from doing so.

Regards,
Andrii


On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt <torsten@lodderstedt.net>= ; wrote:
Hi Andr= ii,

thanks for your post.

The draft is intended to provide AS and RS with a solution to exchange sign= ed (and optionally encrypted) token introspection responses in order to pro= vide 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=E2=80=99m not sure whether there are similar use cases if a client intros= pects a refresh token. What is your use case?

best regards,
Torsten.=C2=A0

> 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 resou= rce 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 w= ill a token introspection response look like when the caller provides a ref= resh 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
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 replace "a resource server&qu= ot; by "the caller" in section 4 (Requesting a JWT Response)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 change "If the access token i= s invalid, expired, revoked" by "If a given token is invalid, exp= ired, revoked" in section 5 (JWT Response)
> If not, my suggestion would be to clarify what the AS should do when i= t asked to introspect the refresh token in general and additionally, what s= hould happen in the same case based on the type of the caller from the AS&#= 39;s point of view.
>
> Regards,
> Andrii
>

--0000000000001fa69c05bac4ec58--