Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

Takahiko Kawasaki <taka@authlete.com> Fri, 29 November 2019 09:36 UTC

Return-Path: <taka@authlete.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 DB418120888 for <oauth@ietfa.amsl.com>; Fri, 29 Nov 2019 01:36:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.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 5LuJ0HW5YDr7 for <oauth@ietfa.amsl.com>; Fri, 29 Nov 2019 01:36:57 -0800 (PST)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 8233C120817 for <oauth@ietf.org>; Fri, 29 Nov 2019 01:36:57 -0800 (PST)
Received: by mail-wm1-x335.google.com with SMTP id l1so13460844wme.2 for <oauth@ietf.org>; Fri, 29 Nov 2019 01:36:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=veBdqcYt/w8nujK+QickquITBjcePNNz9rpmiPte2Hk=; b=a3+H/juh4n9Bp0wtQLhEmvY3QKWvbhGWx3iFhG1T+ZEVVA+Uxj+bmp+JImUllcIwIx KV2YRDHfY9xkR8QprpkKERdZJbySvJ1LrqGW72JNUCCK6fHo0eJN4fuA4v0n3ypxaCrZ SepnV/qZmpLnZlFxTCoOk4gm33nmC4nO+XnFbCOUpJ0s7pk/LDlxmNdckMl+NeoRQiEE qZK3eps9zWvUsMeZmIDEm8Nyp53mkOsPo+x0Ktw5L/eJItvoAbenLiMn31I9PA06s4Dk O6pABrBtFSg/dVc7OTOuQ0zNQZAt3OsUxgvnsA2DRKeMCltctZYGfxfb7BPaI+Oz9eLH 88Pw==
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=veBdqcYt/w8nujK+QickquITBjcePNNz9rpmiPte2Hk=; b=T+AOOnPy+dtlNC4mghRT/U4SSFSN58czBxvFPNsM1qlMSdO8vNEexAplMr113ldwYH 6R+6+XfN6R4f3qporu5+naIPKY4OlbsqaPpMVWIUvEGtc7qa4iTWo+R449JKwn7ZqZJA IwyxiD44GWt1RSpUjbK9H8ARvoTdzFJk2xcY9jELy1cTAkugYdID/DSCJ37MDLMrL0oE ydaXsmJIcm/bokblvtO1qcie61zovGEFScvsH+gBFX47pEyPprF2C75+Ik8SaG34NxbU TdmfA1OwAR1nKE73voXAvEqbMXtPi/hoUNjpGIC87sce6k8lubOFDXzgWaCKTzh6Vj/z vM8Q==
X-Gm-Message-State: APjAAAVfQP6qXFVEeVeleXhM6hQAE+KhJosf8BH6NZfmc5NySKi2XHqH pM6hNywoAs+SaZWGOjB4j7O5ahF3VRCJAz8NZki/CTeIyko=
X-Google-Smtp-Source: APXvYqw3vuEpFkh7kToklfTNkdbjwGHWJROdItrqx8uOIegehjUVjaF/4VFOGZvt1J9WM/qu9kC0L1B137B40roWVv0=
X-Received: by 2002:a1c:a141:: with SMTP id k62mr2336329wme.98.1575020215207; Fri, 29 Nov 2019 01:36:55 -0800 (PST)
MIME-Version: 1.0
References: <CALAqi_-Ku6Hh3DQDXGR+83Q8jofMzVBcW=7GUnFFzsoG+Ka_1g@mail.gmail.com> <CA+k3eCRRW9oLfdmBXsccc_BVd-Ne8qOR5A4HftpSMkMt2JZLRg@mail.gmail.com> <CALAqi_9s+jXDwfb-HK+sguijR6=R6cPgJMwXhSkU52YQcEkX2A@mail.gmail.com> <C73AECC4-5BD0-4939-A51A-8FF57DDE18D6@lodderstedt.net>
In-Reply-To: <C73AECC4-5BD0-4939-A51A-8FF57DDE18D6@lodderstedt.net>
From: Takahiko Kawasaki <taka@authlete.com>
Date: Fri, 29 Nov 2019 18:36:43 +0900
Message-ID: <CAHdPCmPAAZjWUc9u2Z6=smYzmT+dyRxTCKy7Cg=MieUQ+rFaxQ@mail.gmail.com>
To: oauth <oauth@ietf.org>
Cc: Filip Skokan <panva.ip@gmail.com>, Nat Sakimura <nat.sakimura@oidf.org>, Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: multipart/alternative; boundary="000000000000715193059878f835"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/b1syJ3ywCNZCkVC02uwuRkmLBG4>
Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object
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: Fri, 29 Nov 2019 09:37:00 -0000

I'm sorry for this late response, but I'm also afraid that the requirement
"the authorization server supporting this specification MUST only use the
parameters included in the request object." in Section 6 of the draft 20
<https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20> is problematic.

What I'd like to point out in addition to Filip's concerns is "error
handling before the request object is parsed successfully".


   1. If it is not allowed to refer to client_id outside the request
   object, errors that may occur before the request object is parsed
   successfully cannot be reported to the redirect URI (which is either
   explicitly specified by redirect_uri or the default redirect URI for the
   client) because it is impossible to check if the redirect URI has been
   registered for the client.
   2. If it is not allowed to refer to response_type outside the request
   object, it is impossible to determine the default position for response
   parameters (the query part and the fragment part) before the request object
   is parsed successfully.
   3. If it is not allowed to refer to response_mode outside the request
   object, errors that may occur before the request object is parsed
   successfully cannot be reported to the redirect URI in the way the client
   wished (query, fragment, form_post, query.jwt, fragment.jwt or
   form_post.jwt).
   4. If it is not allowed to refer to state outside the request object,
   the state cannot be included in error reporting caused by errors that
   may occur before the request object is parsed successfully.


Decent authorization server implementations try to report errors to the
redirect URI whenever possible. If it is not allowed to refer to parameters
outside the request object, the program waiting for a response at the place
pointed to by the redirect URI will never receive
error=invalid_request_object when the cause is "the request object failed
to be parsed".

I haven't found any convincing reasons yet that can justify introducing the
requirement that dares to break the backward compatibility. For me, the
following requirement in FAPI Part 2
<https://openid.net/specs/openid-financial-api-part-2-ID2.html>, 5.2.2.
<https://openid.net/specs/openid-financial-api-part-2-ID2.html#authorization-server>,
10. seems a good compromise.

shall require that all parameters are present inside the signed request
object passed in the request or request_uri parameter;



Best Regards,
Takahiko Kawasaki
Authlete, Inc.



On Thu, Aug 29, 2019 at 5:04 PM Torsten Lodderstedt <torsten@lodderstedt.net>
wrote:

>
>
> > Am 28.08.2019 um 23:23 schrieb Filip Skokan <panva.ip@gmail.com>om>:
> >
> > - allows merging request object and regular parameters with request
> object taking precedence since it is a very useful feature when having
> pre-signed request object that's not one time use and clients using it wish
> to vary state/nonce per-request.
>
> +1_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>