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

Filip Skokan <panva.ip@gmail.com> Wed, 28 August 2019 21:38 UTC

Return-Path: <panva.ip@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 AF80D120089 for <oauth@ietfa.amsl.com>; Wed, 28 Aug 2019 14:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 5W2HgXPKxQ4j for <oauth@ietfa.amsl.com>; Wed, 28 Aug 2019 14:38:45 -0700 (PDT)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 82666120059 for <oauth@ietf.org>; Wed, 28 Aug 2019 14:38:45 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id t17so1560932wmi.2 for <oauth@ietf.org>; Wed, 28 Aug 2019 14:38:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JIHp3aYI7erKFH10r77NOQobL7sgUvg1Fpiwhu+sd6c=; b=RWzE1XtSFosQGynE0PPok3rIpd2EXSTk+/SyGqKmioOqkfGn53dqurIhVS8+FqZPXM U7Al1AB7fEHYFT8597ZXSl+MHRILzF83L+SQ1fCQZMaf3aE8Y365pJVHVtpW8Wa2h5fO nJSCv6nqQhrDO60a/c8Fqc2PEBJcXQkOwE+X4ovYP5YlBKs7N6EOy3JCIzrJKwWdIAdg jRPwAbuk3rXWfaBtbnYWUPJi/CXeCqAgVZEu2JLMEp/HGqMAnlVfPQPoYe5RT7FDy/7D gnAzgWYkvSZeZZ2YNgHOXp0h+4M4jCn5QeDMOIzAGOWUdCP9x8OAVshbE6B814xOYvdo dLBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JIHp3aYI7erKFH10r77NOQobL7sgUvg1Fpiwhu+sd6c=; b=OiyOKgPepnstdN8FwHLGnwS9vkDNVs4chf9UDlIp83BAn5VZcAbdFU3YEOGl4dgdoQ E7hUy/KB240rfhhG7/5lZCW5M33+5JTg9OyAZIdiDA7rzAxPlilaIS1PHsIj5jmF3l/w /9Khxnj5VlsdsZgClNtKvu2fHkqPselVeuO+T+l61qWFBtS1lAf6eBQEnjEXgQIg1iMK OFPINbBYcYm3acDbzPKe/U1SbBjlBOt9okc+2wSKP+CPmNRpgFKBU9kG9RE12Z6j9Epz 5aUMRJFNZJXv1bDFUHWQcI+oN4nzDM92RPK4nAsh7h8L3T6lpXyZnsON3dYElx1Wytem 2uhg==
X-Gm-Message-State: APjAAAUoMN6Q0rE3Tzz9dlsp0phqJN0E8ITGuFrz+WdZuiXsUcrlAauf 49kTnAzYtbex7WR2vAtt4Q==
X-Google-Smtp-Source: APXvYqxd6SvmyeNjhRVfIk/9VDrB7JoeCXjDIx7z0Dtb0ZeW5rFZ4ogjDDBefPV+0AC+TqA7duIHAw==
X-Received: by 2002:a1c:b6d4:: with SMTP id g203mr7263583wmf.100.1567028323907; Wed, 28 Aug 2019 14:38:43 -0700 (PDT)
Received: from [100.96.66.97] (ip-37-188-149-253.eurotel.cz. [37.188.149.253]) by smtp.gmail.com with ESMTPSA id a17sm408609wmm.47.2019.08.28.14.38.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Aug 2019 14:38:43 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-BA0F4F27-401A-4A37-9AF7-7DE3DC512D63
Mime-Version: 1.0 (1.0)
From: Filip Skokan <panva.ip@gmail.com>
X-Mailer: iPhone Mail (16G77)
In-Reply-To: <CALAqi_9s+jXDwfb-HK+sguijR6=R6cPgJMwXhSkU52YQcEkX2A@mail.gmail.com>
Date: Wed, 28 Aug 2019 23:38:42 +0200
Cc: oauth <oauth@ietf.org>, Nat Sakimura <nat.sakimura@oidf.org>, John Bradley <ve7jtb@ve7jtb.com>
Content-Transfer-Encoding: 7bit
Message-Id: <0265E9D0-E507-4B83-8872-33E64142EE68@gmail.com>
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>
To: Brian Campbell <bcampbell@pingidentity.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/iqJzfwNNRvoGnrAvo2XPUK0Uq1U>
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: Wed, 28 Aug 2019 21:38:50 -0000

It would be fine not allowing that across the board but rather through a language like so

‘Authorization Servers MAY allow per-transaction parameters such as “state” and “nonce” to be sent outside of the Request Object using regular OAuth 2.0 parameter syntax, the specific parameters are at the implementer’s discretion’

Odesláno z iPhonu

28. 8. 2019 v 23:23, Filip Skokan <panva.ip@gmail.com>om>:

> Well it kind of blows, doesn't it? I wasn't able to find the "why" anywhere in the mailing list archive around the time this was changed.
> 
> My take on satisfying both worlds looks like this
> 
> - allow just JAR - no other params when possible.
>     (which btw isn't possible to do with request_uri when enforcing client based uri whitelist and the jwsreq 5.2.2 shows as much)
> - enforce the "dupe behaviours" defined in OIDC (if response_type or client_id is in request object it must either be missing or the same in regular request).
> - 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.
> 
> I wish the group reconsidered making this breaking change from OIDC's take on request objects - allow combination of parameters from the request object with ones from regular parameters (if not present in request object).
> 
> S pozdravem,
> Filip Skokan
> 
> 
>> On Wed, 28 Aug 2019 at 23:02, Brian Campbell <bcampbell@pingidentity.com> wrote:
>> Filip, for better or worse, I believe your assessment of the situation is correct. I know of one AS that didn't choose which of the two to follow but rather implemented a bit of a hybrid where it basically ignores everything outside of the request object per JAR but also checks for and enforces the presence and value of the few regular parameters (client_id, response_type) that OIDC mandates. 
>> 
>>> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan <panva.ip@gmail.com> wrote:
>>> Hello everyone,
>>> 
>>> in an earlier thread I've posed the following question that might have gotten missed, this might have consequences for the existing implementations of Request Objects in OIDC implementations - its making pure JAR requests incompatible with OIDC Core implementations.
>>> 
>>> draft 14 of jwsreq (JAR) introduced this language
>>> 
>>>> The client MAY send the parameters included in the request object
>>>> duplicated in the query parameters as well for the backward
>>>> compatibility etc.  However, the authorization server supporting this
>>>> specification MUST only use the parameters included in the request
>>>> object. 
>>> 
>>>> Server MUST only use the parameters in the Request Object even if the
>>>> same parameter is provided in the query parameter.  The Authorization
>>> 
>>>> The client MAY send the parameters included in the request object
>>>> duplicated in the query parameters as well for the backward
>>>> compatibility etc.  However, the authorization server supporting this
>>>> specification MUST only use the parameters included in the request
>>>> object. 
>>> 
>>> Nat, John, everyone - does this mean a JAR compliant AS ignores everything outside of the request object while OIDC Request Object one merges the two with the ones in the request object being used over ones that are sent in clear? The OIDC language also includes sections which make sure that some required arguments are still passed outside of the request object with the same value to make sure the request is "valid" OAuth 2.0 request (client_id, response_type), something which an example in the JAR spec does not do. Not having this language means that existing authorization request pipelines can't simply be extended with e.g. a middleware, they need to branch their codepaths.
>>> 
>>> Is an AS required to choose which of the two it follows?
>>> 
>>> Thank you for clarifying this in advance. I think if either the behaviour is the same as in OIDC or different this should be called out in the language to avoid confusion, especially since this already exists in OIDC and likely isn't going to be read in isolation, especially because the Request Object is even called out to be already in place in OIDC in the JAR draft.
>>> 
>>> Best,
>>> Filip
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 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.