Re: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-par-08: (with COMMENT)
Brian Campbell <bcampbell@pingidentity.com> Wed, 30 June 2021 21:12 UTC
Return-Path: <bcampbell@pingidentity.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 A58443A2B23 for <oauth@ietfa.amsl.com>; Wed, 30 Jun 2021 14:12:34 -0700 (PDT)
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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.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 EyBYRgVJQbay for <oauth@ietfa.amsl.com>; Wed, 30 Jun 2021 14:12:29 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 16A193A2B22 for <oauth@ietf.org>; Wed, 30 Jun 2021 14:12:28 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id q18so7667483lfc.7 for <oauth@ietf.org>; Wed, 30 Jun 2021 14:12:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RcfgycE3jjaDiRBXeDEhor62y3wHbwDR0P+zCQiP47o=; b=T1WROlKmXWBN4SJQ7zDfthiAacaO+AqOrDEO/NWcSBsByQGVAwMYUz7UiDhq8Qi6ym 75m7WCPqhHoxdMjhY/hp/eeDRy0hUYZ6nx43Bgdt/F73+NiFNzdWjxh37MSyZ10api2V NFnDBwMpzou7vO/V4YDwSIUWUOQWjEyMIhAWGPzRSNFcaK5QexdD78V3PeMAXKKc1SZ9 bwMPud7NVIXBikNC1zY2aSP8CxKU7HuLK65k0lTrGluJ65qeANdMBhi+Co5MatanrcZE IsbJ8pvLEfs2HsMhs9a6yMAj2TAWx+R4+5bC6wn+f/I9wvl/4uo/5fzYs0n+7JUk9Wtg qLnA==
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=RcfgycE3jjaDiRBXeDEhor62y3wHbwDR0P+zCQiP47o=; b=U53fI5/Oy206fOa07vYO+iiBO5zFNH75iAKB5hlfcbkwiJIKmvRyULlr3245OY5Eh7 ThSiVzBjchiRkjsfTakD6xLg758jugSl2JiFLW1m5fES36hC28f2QTY3sIMzHoG+oeeS 9UMGRxne8Uov/A1muejccXryjqpqF+nGQIYzUggJXoZDr/eBfVAo6pV4OSwBrEgomXXt erd+iOWMOqdlTqjNPlt/td38AzlZewX1t0djSdcFlulIPAxwpFJu5wjVkp+wIEHe7+uN LBix2G6+amMhzW4kSaYxlPrP44CeSeDs82nPJkt6hstcmP965JDERMIPqoJbuLI479j/ 9fcw==
X-Gm-Message-State: AOAM531WHv3JpQL9AtWt+PevaaeF2W41hch+q0/kesbQNpXXk8fr41/v f87pZVuu+m5MJLfLO4FgOuUnH3zIXGi1if/N/AACK5oImIowiiJ1VuhcP2hJyjStUtpRRJ8J6yA MhNiB2YTQR1hwkw==
X-Google-Smtp-Source: ABdhPJxyxfpMpY07sp9u/rYJywTXGoP4sdAjjiSrhYsnF8K8C3TxeAL1IByHT6rSLFuH6PtxXhwS/whM+xBLZrHeoCk=
X-Received: by 2002:ac2:4187:: with SMTP id z7mr11602911lfh.574.1625087546173; Wed, 30 Jun 2021 14:12:26 -0700 (PDT)
MIME-Version: 1.0
References: <162495689162.17201.16673826726221874767@ietfa.amsl.com>
In-Reply-To: <162495689162.17201.16673826726221874767@ietfa.amsl.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 30 Jun 2021 15:11:59 -0600
Message-ID: <CA+k3eCQcouZOVbeN96pbKny5MBBf=463g4nrDyPFzWx2SmGN_w@mail.gmail.com>
To: Robert Wilton <rwilton@cisco.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-oauth-par@ietf.org, oauth-chairs@ietf.org, oauth <oauth@ietf.org>, Hannes Tschofenig <hannes.tschofenig@arm.com>
Content-Type: multipart/alternative; boundary="000000000000eb55df05c6022dcb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/rkQZ8PzYeAFBarRAelh0UX9fBqM>
Subject: Re: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-par-08: (with COMMENT)
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: Wed, 30 Jun 2021 21:12:35 -0000
Thanks for the review Rob. I've endeavored to reply to your comments inline below. On Tue, Jun 29, 2021 at 2:54 AM Robert Wilton via Datatracker <noreply@ietf .org> wrote: > Robert Wilton has entered the following ballot position for > draft-ietf-oauth-par-08: No Objection > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi, > > Thanks for this document. Outside my area of expertise, but I have a > couple of > questions/comments: > > Section 2: > Due to historical reasons there is potential ambiguity regarding the > appropriate audience value to use when employing JWT client assertion > based authentication (defined in Section 2.2 of [RFC7523] with > "private_key_jwt" or "client_secret_jwt" authentication method names > per Section 9 of [OIDC]). To address that ambiguity the issuer > identifier URL of the authorization server according to [RFC8414] > SHOULD be used as the value of the audience. In order to facilitate > interoperability the authorization server MUST accept its issuer > identifier, token endpoint URL, or pushed authorization request > endpoint URL as values that identify it as an intended audience. > > I may be misunderstanding this text, but I note that by giving flexibility > to > the client (i.e., the SHOULD) and being strict on the receiver (MUST > support x, > y, z), this seems to encourage a proliferation. Hence, I was wondering > whether > this might be better the other way round. I.e., be strict with what is > sent, > and less strict with what is received: MUST send 'issuer identifier', MUST > receive 'issuer identifier', SHOULD receive 'token endpoint URL' and > 'pushed > authorization request endpoint URL'? > While definitely not trying to encourage proliferation, the text is aiming to help interoperability while also accounting for the treatment in other documents (RFC7523/21) and existing implementations while also allowing for consistent processing to be implemented across the different endpoints where JWT client assertion based authentication can be employed. It's kinda tricky and I don't know for sure that the current text is exactly right but it's made it through the WG process and seen a number of implementations. > 2. > * "expires_in" : A JSON number that represents the lifetime of the > request URI in seconds as a positive integer. The request URI > lifetime is at the discretion of the authorization server but will > typically be relatively short (e.g., between 5 and 600 seconds). > > JSON numbers are doubles, but the value is a positive integer. Does it > make > sense to put in a hard limit of 2^53, or given that these are expected to > be > small numbers, 2^31 - 1? > I think the soft general guidance is enough and don't believe a hard upper limit is needed. 3. The success and error examples both define: > Content-Type: application/json > Cache-Control: no-cache, no-store > > The document states that the response should be JSON, but should it more > specifically specify the content type as "application/json"? Yeah, it probably should be that specific. I'll add the content type specificity to the document. > Similarly, the > cache control makes sense, but should the document mandate that the > response > must include "Cache-Control: no-cache, no-store"? > Although it makes sense not to cache I'm less comfortable mandating cache control stuff - particularly for a response to a POST (that I'm not sure is ever cacheable anyway) and for a client that is most likely not doing any caching at all and would immediately encounter failures if it were. Regards, > Rob > > > > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
- [OAUTH-WG] Robert Wilton's No Objection on draft-… Robert Wilton via Datatracker
- Re: [OAUTH-WG] Robert Wilton's No Objection on dr… Brian Campbell
- Re: [OAUTH-WG] Robert Wilton's No Objection on dr… Rob Wilton (rwilton)
- Re: [OAUTH-WG] Robert Wilton's No Objection on dr… Brian Campbell
- Re: [OAUTH-WG] Robert Wilton's No Objection on dr… Rob Wilton (rwilton)