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

Brian Campbell <bcampbell@pingidentity.com> Wed, 28 August 2019 21:02 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 EB7E5120089 for <oauth@ietfa.amsl.com>; Wed, 28 Aug 2019 14:02:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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 (1024-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 28oY7-qycv8B for <oauth@ietfa.amsl.com>; Wed, 28 Aug 2019 14:02:22 -0700 (PDT)
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 7B09012004C for <oauth@ietf.org>; Wed, 28 Aug 2019 14:02:22 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id s21so2498599ioa.1 for <oauth@ietf.org>; Wed, 28 Aug 2019 14:02:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Id6KB368tjk5iqlYbJkv2/OrOKSt5gd83pe0A5ibMhM=; b=iTt/MnAn/os/6mMvNw/PQQHLUhUtOfD+LuuRhASXM+HA9vONBlFfLuLs9WU2pRyHxy sQ1dWINcYeF0SE569Yi1bVCebvY3lNnQt6CdBz+UufFZ6uYiEKNJcQFryBbo+MiV+7Rd kdJYnJHrUonOXpodHRQgpqtpRVsZyXl671JtU=
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=Id6KB368tjk5iqlYbJkv2/OrOKSt5gd83pe0A5ibMhM=; b=cjyR+gaICvdm2SsJ2i86iAH0BWJPwCXHKpHUGt+vn3dAZtqsPKiibP1LCF54UM7267 8d6d2RFf003jD3gePXWw8ZbirxT3gXqx7hq+raneqQbntzaGn+gTq5daJ9Cbc5qNHtr/ d8EpOzLfLeDK1+u37Rgt8trU3nesmPmp+OZ45bLxogS3w5l+jL43SshdYDAEbmp8/5o/ +6LeWlzUtrqM4Z8QpIDRpwVwEZ/JY9OkPyGh1tqQg1/3lcG/KWXejEULSMUDie6vfORb wgP9K1Jb5GP0EHna4WvuHIOfHZQmGs/TWWNb4/lHMzEKOvQXgmVokGFtaQTfTorKrn3M WN+g==
X-Gm-Message-State: APjAAAWqKIsirGcmQhe6Iz/Nf4NrntX3Q0LlcMhmwiCXbSb6sDOnRdjU mnu/z7bd2yCTJZ3zKwMaRoNBXXfun+enTNF2oaEFr/hU46UZW0UXSmiJSV36QtkFjN6YxcoKa9s x0tbWBvIoHd1dZQ==
X-Google-Smtp-Source: APXvYqxTFGlkAvCyitoYOdAhvu1DD3bSA9TtBYaJju8qMwNjDASyr4ODSj+MdgfDTSUcKWff1ZUG0kF0/4GPYVbkRkc=
X-Received: by 2002:a5e:9244:: with SMTP id z4mr6633412iop.127.1567026141682; Wed, 28 Aug 2019 14:02:21 -0700 (PDT)
MIME-Version: 1.0
References: <CALAqi_-Ku6Hh3DQDXGR+83Q8jofMzVBcW=7GUnFFzsoG+Ka_1g@mail.gmail.com>
In-Reply-To: <CALAqi_-Ku6Hh3DQDXGR+83Q8jofMzVBcW=7GUnFFzsoG+Ka_1g@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 28 Aug 2019 15:01:55 -0600
Message-ID: <CA+k3eCRRW9oLfdmBXsccc_BVd-Ne8qOR5A4HftpSMkMt2JZLRg@mail.gmail.com>
To: Filip Skokan <panva.ip@gmail.com>
Cc: oauth <oauth@ietf.org>, Nat Sakimura <nat.sakimura@oidf.org>, John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary="0000000000008775cd059133b47c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/8HhtptqKk5_CDt4z5fqQhjLC3Sk>
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:02:25 -0000

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 thisspecification MUST only
>> use the parameters included in the requestobject. *
>
>
> 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 thisspecification MUST only
>> use the parameters included in the requestobject. *
>
>
> 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._