Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAuth Token Introspection) to Proposed Standard
Dick Hardt <dick.hardt@gmail.com> Thu, 27 August 2020 16:16 UTC
Return-Path: <dick.hardt@gmail.com>
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 EAA7E3A104B; Thu, 27 Aug 2020 09:16:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_FONT_LOW_CONTRAST=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 VCuJrmI_KMBR; Thu, 27 Aug 2020 09:16:32 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 5BD863A104C; Thu, 27 Aug 2020 09:16:32 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id f26so7052149ljc.8; Thu, 27 Aug 2020 09:16:32 -0700 (PDT)
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=QqYeq+qjhVgwubr9DEOHZV/1F/DCnfxJ/5+s5bQv+fU=; b=kK1BVmP+rC0eK6A835FCGfy8W1jd9/h1wqrAwiZLo30gl+uFBrs3YWGf45GmvZSAMT dnySWZ/d35u3EnbQNFDClTmc5ZdDTDcTGU/uV/3OgM6bzgaUVAYplYA6USlm9cqzCtY0 oqSC3guiRgUd3eBgCGJCkqnuaS8sSsibr4TPcVhc9ZR1ndbI+hMYYwpAJztwG+uAtFai vjxAyZPd3bBUqPoZZPSHvfhyc3yrbERCsFlEL/eBx5YI8i7L+nx+LTl+e3+uE17ARZAU sVAfim+NBUuZEjd1NcFW+xIu7Ky6dhwKAXI37BcPaPWWlOvQObhDuLHMY2IluO/l0/41 ROSA==
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=QqYeq+qjhVgwubr9DEOHZV/1F/DCnfxJ/5+s5bQv+fU=; b=d1Dl1sXM9xv5sLVYSceiYhaiAZgs3vMxu90Vr2YpK3SaZEMlQsvRwiN6H4uKvdNDVg l6ahfJbZU72pIT/u+J0k5pSt4EJcuuhQ3K3ilDROyapGlYjsMeWdi9E44tGPuuBKKog+ kqr6TPzB73l0aCzd9A1gK2waGbI5Rl1h9Pmf60C9s18+f4DjTSeR1Rwhh+U8uvNlzvPo lALN0+hIs4hAVBb8UEd/XHaQphbzdbzSgxy1ZlyR0ebIsynCRUVh/YTEaDE+pKRdGquU 7R1VpajeudZZy+OrQi/XpOJcWYT7SsWxh/oA4quc2q0GG1FHUMEzQDNqhtBk+mlNB9HC C/LA==
X-Gm-Message-State: AOAM532prZDM/2lOVMfYXuGcacmVMrUIaCne777bVedVQdoNStjSa4ui kJe+JU8TGMOeTckxH8lMdjz0uC2KUNcO0T1KduNnBFVm2jHKAQ==
X-Google-Smtp-Source: ABdhPJyx6y3TprROjFJHmni+DyM7ZTeEzh53MgXQdSpKxciyq2kLUE8oBG2hrMz0e1pU6s+5qmrzsmOaONqnmQAxfOk=
X-Received: by 2002:a2e:7215:: with SMTP id n21mr10718610ljc.242.1598544990440; Thu, 27 Aug 2020 09:16:30 -0700 (PDT)
MIME-Version: 1.0
References: <CH2PR00MB0678DA2BC7234C2AC1CE784DF5541@CH2PR00MB0678.namprd00.prod.outlook.com> <412A63AD-DDE1-4BFE-8234-5A721A0ED88D@lodderstedt.net> <D68FCD40-7365-446A-9F64-2BB59C11B7AE@mit.edu>
In-Reply-To: <D68FCD40-7365-446A-9F64-2BB59C11B7AE@mit.edu>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Thu, 27 Aug 2020 09:15:53 -0700
Message-ID: <CAD9ie-uqeM5jwQKuvO+X4NC5oXZkoLrRu1NWC2rrE4CD=ypa+g@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005011a205adde42c2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/uMMNM63noJ6SVPFyIqU0a-niSp4>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAuth Token Introspection) to Proposed Standard
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: Thu, 27 Aug 2020 16:16:35 -0000
Here is a crisper revision. Implementers should be aware that a token introspection request lets the AS know when the client is accessing the RS, which may indicate when the user is using the client. If this implication is not acceptable, implementers can use other means to carry access token data, e.g. directly transferring the data needed by the RS within the access token. ᐧ On Thu, Aug 27, 2020 at 7:19 AM Justin Richer <jricher@mit.edu> wrote: > I would clarify that this doesn’t necessarily say that the user’s there, > and remove the normative requirement (which doesn’t have enforceable teeth > in this context): > > Implementers should be aware that a token introspection request lets the > AS know when the client > (and potentially the user) is accessing the RS, which *can also > indicate* when the user is using > the client. If this implication is not acceptable, *implementers can > use other means* to carry > access token data, e.g. directly transferring the data needed by the > RS within the access token. > > > — Justin > > On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt < > torsten=40lodderstedt.net@dmarc.ietf.org> wrote: > > Will the following text work for you? > > Implementers should be aware that a token introspection request lets the > AS know when the client > (and potentially the user) is accessing the RS, which is also an > indication of when the user is using > the client. If this impliction is not accepatable, implementars MUST > use other means to carry > access token data, e.g. directly transferring the data needed by the > RS within the access token. > > > On 26. Aug 2020, at 23:12, Mike Jones < > Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote: > > I agree with Dick’s observation about the privacy implications of using an > Introspection Endpoint. That’s why it’s preferable to not use one at all > and instead directly have the Resource understand the Access Token. One > way of doing this is the JWT Access Token spec. There are plenty of others. > > The downsides of using an Introspection Endpoint should be described in > the Privacy Considerations section. > > -- Mike > > From: OAuth <oauth-bounces@ietf.org> On Behalf Of Dick Hardt > Sent: Wednesday, August 26, 2020 9:52 AM > To: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org> > Cc: last-call@ietf.org; oauth <oauth@ietf.org> > Subject: Re: [OAUTH-WG] Last Call: > <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for > OAuth Token Introspection) to Proposed Standard > > > > On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt < > torsten=40lodderstedt.net@dmarc.ietf.org> wrote: > Hi Denis, > > On 25. Aug 2020, at 16:55, Denis <denis.ietf@free.fr> wrote: > > > The fact that the AS will know exactly when the introspection call has > been made and thus be able to make sure which client > has attempted perform an access to that RS and at which instant of time. > The use of this call allows an AS to track where and when > its clients have indeed presented an issued access token. > > > That is a fact. I don’t think it is an issue per se. Please explain the > privacy implications. > > As I see it, the privacy implication is that the AS knows when the client > (and potentially the user) is accessing the RS, which is also an indication > of when the user is using the client. > > I think including this implication would be important to have in a Privacy > Considerations section. > > /Dick > ᐧ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > >
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Torsten Lodderstedt
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Torsten Lodderstedt
- [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-intro… The IESG
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Denis
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Denis
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Dick Hardt
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Justin Richer
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Mike Jones
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Torsten Lodderstedt
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Justin Richer
- Re: [OAUTH-WG] [Last-Call] Last Call: <draft-ietf… Brian Campbell
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Dick Hardt
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Justin Richer
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Dick Hardt
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Denis
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Neil Madden
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Jeff Craig
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Dick Hardt
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Neil Madden
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-i… Benjamin Kaduk
- [OAUTH-WG] Towards an RFC Errata to RFC 7662 ? Denis
- Re: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ? Justin Richer
- Re: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ? Manger, James
- Re: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ? Benjamin Kaduk