Re: [OAUTH-WG] PAR - Can AS/client require request object?

Brian Campbell <> Mon, 27 April 2020 18:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF2263A18BD for <>; Mon, 27 Apr 2020 11:57:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XS2w-y_Hd25q for <>; Mon, 27 Apr 2020 11:57:01 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64E733A18B8 for <>; Mon, 27 Apr 2020 11:57:01 -0700 (PDT)
Received: by with SMTP id u6so18746162ljl.6 for <>; Mon, 27 Apr 2020 11:57:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AElps0yRj1e0kBihiZ0fDAn6ZxYxwT5YS5CbqktpLNA=; b=Hx7FDO1YJDCS8u8pSOZ6bXJyNEQumP0L3cGGhoLM26x03lc6+osDFXWyZfNC0t0DeN kva4S6QNd4jkdKz/LlflLGruUoD+2+wlw3vjtSa8kEKcTRSjyjHvfnsouj5cFJ4fKG4O dqBWeHZwkdrDk+supms/gp25JM1bVOy2JK6UYRE+868NkB2NvHbgk+dkDWBcfwTBr/7S aQPZHQC4+zLW/m775JmP0pCnJ/Me1tn0H25Bp/rNswE0aglcSf9YWt691iGsRpwoAQBu l+jPVZnuk1lFZHT7eCIPjMOFTy6rnRadri0xYPkZGk/ThfPJl/7V76A3yV0tyvHe6XwX F+Dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AElps0yRj1e0kBihiZ0fDAn6ZxYxwT5YS5CbqktpLNA=; b=PsD2Uk30dixJdDPvMeeS/EHRnpfC+e8O6N5MdRf/zxLPpikYAm9iDnBAV1JHSMvnT2 85HJZTMQ4DlP2ZIKpekN8zMRXo8q3wSahqPmQ7XsP8rM18CnNBZi+5kjjvpxxo5snqH5 ApP0Q34aebnlTfGuRJs4tmTopnEnx3pQ4MwXJUy85J807o778snFmE+quSRBz0TyCkK4 WvFj92USmTk8Nm/+F2IrYCEZM9EXJ2QTICwomtrrX1ncsHLnoFpih8f+bekA8pr70nTL kz5Kxh8zauiceHcHsJ/12wT3RYL+jf/VUXdBouugdVgbWuxx38OJSD6DbBaQ1O3mcCCd f/7Q==
X-Gm-Message-State: AGi0PuZs7gNGffkrb85RKa+F1KMbW2I6b+AqgHcBzLRy4agugpShjQIr t2NNQbUnYZWsG0z4+iVfb52N2ANkBhrlQbp9dWh6xISaS8wVHgai89hzlVihSmdtQOfMNHbx/2F ngUx7KH0VNSwV5w==
X-Google-Smtp-Source: APiQypId/R22VIRRY8n9WYpUirXbdjD0SIxDG8jFMGU6oho8ejWI3hzC0Tn0XwkRvBr/PgJxGG7Ji98wn0n83BioBqw=
X-Received: by 2002:a05:651c:505:: with SMTP id o5mr8864482ljp.0.1588013819423; Mon, 27 Apr 2020 11:56:59 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Mon, 27 Apr 2020 12:56:33 -0600
Message-ID: <>
To: Filip Skokan <>
Cc: Torsten Lodderstedt <>, oauth <>
Content-Type: multipart/alternative; boundary="0000000000009b08a805a44a47c0"
Archived-At: <>
Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Apr 2020 18:57:04 -0000

While there are certainly different permutations and contexts of use that
could be imagine, I tend to agree with Filip here in not seeing a strong
need to define new PAR specific metadata around signing/encryption of the
request object.

On Mon, Apr 27, 2020 at 2:35 AM Filip Skokan <> wrote:

> Considering there's going to be a setting that forces clients to use PAR
> (other mailinglist thread), then we should rely on the existing
> `request_object_signing_alg` presence to indicate a Request Object must be
> used (as suggested by this upcoming OIDC Core errata
> <>),
> regardless of it being PAR or JAR. I don't see the need for a PAR specific
> metadata, for one - implementations wouldn't be easily able to re-use of
> existing pipelines, two - yes the contexts differ but do you think clients
> will be using both channels at the same time? And even if so, the Request
> Object is the same therefore its applicable to both channels the same.
> Best,
> *Filip Skokan*
> On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt <torsten=
>> wrote:
>> Hi all,
>> this is one of the topics we quickly flipped through in the virtual
>> meeting last week.
>> I see the following open questions:
>> - Can the client require its instances to use request objects only.
>> - Are there further requirements on the properties of these objects?
>> Signed only, Signed and encrypted, algorithms?
>> - Can an AS require ALL clients to use request objects only?
>> - Further requirements here as well?
>> - Is this tied to PAR or relevant for JAR as well?
>> In my opinion, client as well as AS should be able to control enforced
>> use of request objects.
>> I could imagine the setting for JAR request objects (“request" parameter)
>> and request objects in the PAR context differ, as the first case goes
>> through the user’s browser whereas the PAR case goes direct from client to
>> AS via a TLS protected channel. I therefore feel the settings should be PAR
>> specific.
>> What do you think?
>> best regards,
>> Torsten.
>> _______________________________________________
>> OAuth mailing list
> _______________________________________________
> OAuth mailing list

_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._