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

Warren Parad <wparad@rhosys.ch> Mon, 08 February 2021 09:07 UTC

Return-Path: <wparad@rhosys.ch>
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 82CC93A14E9 for <oauth@ietfa.amsl.com>; Mon, 8 Feb 2021 01:07:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 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, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
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 cuGThtu6eLKd for <oauth@ietfa.amsl.com>; Mon, 8 Feb 2021 01:07:29 -0800 (PST)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 4676E3A14E5 for <oauth@ietf.org>; Mon, 8 Feb 2021 01:07:29 -0800 (PST)
Received: by mail-io1-xd31.google.com with SMTP id n14so14214922iog.3 for <oauth@ietf.org>; Mon, 08 Feb 2021 01:07:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cgOXSqqMZpuNze4EifbCezvKpMaUiFsFTPz76DkKNz4=; b=fCcXwTanT+Pd+8pn0yJT5ZnE/yXxlyOuoYXQ1i0e48PZYiE70rUZ7Z/67le3Yl1Tev zNHHwtPp/wtODW4VjhRtWYSlQMt1X0YnU5hutLlR21rbnHvP0QiqcZveMXBi4QEQaBVv dKOIPPXE8CqZx61tD3tpiDR2SdRE368wl/8MEHV/0ophApmv9bv9G3NEcJ9zfchT3yLJ DGyJ4zP/sc1L4YCpW8bvW9g4SLpL/kPAYcdrkBd+M54ZU/S+ZYYWbHz2qjxX8A9+fr5O DWejp4VYj/sKADESF41NOvJ9uvx9h4bYVsk0mnVDxgYKEK6WIMpyKP4kkZe1aD01+0fg upqg==
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=cgOXSqqMZpuNze4EifbCezvKpMaUiFsFTPz76DkKNz4=; b=rP+1rX3ZhJ88023psJuBuJ2HG9tZ2VcL9BKuZ2UOC8Cf3I1V16+ywaIZbqRVyTcC5g RTivxUpJnyjy5le0leuwKI8FTvaisqAJATYel597mb6w4nw/vReaHcpNq+B+tKRTZyFX ZFiHjOiSQh/x7TZxWrgc3yCy6mROYXhs0JKCZWW0oWDxObPUV2X5E0+YW5ZDEDAakGMf f6AcVIlNMUR/4qKZ/76G0sqwYdE5IaCrBF2BLd1UBJuaWieCVV5w2+kQAviszqH9FeQG d0D2GzilXzh+moXT+1uiTyXppRtZS2iYmp5465iRnhJjiM5lPktpUQqSz9CH8JsyTpjh JIyA==
X-Gm-Message-State: AOAM533WpYJrv9wQF+7WT5lS6MVLvj9x2RUUUE0rXKBf8e0Th57nQ7ni sSr9q6zcRlj3q/Kaa00Hw8HGA2Ym7KaT7xnfjS2y
X-Google-Smtp-Source: ABdhPJxYV2I08y5DgHE7IRnyLIevzAeE/mjzgAAAxxNi7vH9lqnlVO1VOpitUFSJP0JXY0lPHTCDruw3cwb+ptmDa9g=
X-Received: by 2002:a6b:da0f:: with SMTP id x15mr14137422iob.48.1612775248375; Mon, 08 Feb 2021 01:07:28 -0800 (PST)
MIME-Version: 1.0
References: <CAJot-L05Nb5FQQ_OOgW_s4Mswo0GW3-j7HTTxtbR2OgqESijWg@mail.gmail.com> <579E1C30-107C-43E6-A521-01A674DAB0F3@lodderstedt.net>
In-Reply-To: <579E1C30-107C-43E6-A521-01A674DAB0F3@lodderstedt.net>
From: Warren Parad <wparad@rhosys.ch>
Date: Mon, 08 Feb 2021 10:07:19 +0100
Message-ID: <CAJot-L1tMjM=JHtn3sHROLtzoxAkOGr33m66mcRH9-Vvss6QRg@mail.gmail.com>
To: torsten@lodderstedt.net
Cc: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>, Andrii Deinega <andrii.deinega@gmail.com>, oauth <oauth@ietf.org>, draft-ietf-oauth-jwt-introspection-response@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c84a8305bacf7f12"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/hoBZ9qONry7q7UEAHo95iIYW6u8>
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: Mon, 08 Feb 2021 09:07:32 -0000

It doesn't work that way. You suggested to add language to the draft, that
means the burden of proof is on you to justify adding it.

Otherwise I could just say why not?

And I can go stronger, what's the purpose of nho introspection endpoint at
all, and why encourage sending access tokens to the AS?

Even if you can justify access tokens, there currently isn't evidence
provided why we should explicity discourage.


On Mon, Feb 8, 2021, 03:18 Torsten Lodderstedt <torsten@lodderstedt.net>
wrote:

>
>
> Am 08.02.2021 um 00:56 schrieb Warren Parad <wparad@rhosys.ch>:
>
> 
>
>> I‘m therefore leaning towards explicitly stating in our draft that it is
>> not intended to be used with refresh tokens.
>
> I'm not following, why explicitly state that it isn't intended. If an AS
> wants to provide a similar JSON response to a query with the refresh token,
> why not encourage that?
>
>
> Why should we encourage it?
>
>
> Warren Parad
>
> Founder, CTO
> Secure your user data and complete your authorization architecture.
> Implement Authress
> <https://www.google.com/url?q=https://authress.io&source=gmail-imap&ust=1613346997000000&usg=AOvVaw267Z448csTGn3F6REIQ9pT>
> .
>
>
> On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt <torsten=
> 40lodderstedt.net@dmarc.ietf.org> wrote:
>
>> 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
>>> >
>>>
>>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1613346997000000&usg=AOvVaw3ZHWt08dlcHAgxyfj2hrsX>
>>
>