Archive

I think require_request_objects has its place, that place should be JAR,
PAR as a backup. I believe doing only the "PAR-specific" name / meaning of
it would be a missed opportunity.

S pozdravem,
*Filip Skokan*

On Tue, 12 May 2020 at 08:27, Torsten Lodderstedt <torsten=
40lodderstedt.net@dmarc.ietf.org> wrote:

> Hi all,
>
> I initially raised the question whether the AS should be able to require
> request objects for all clients (in the same way as we decided to let the
> AS required PAR for all clients) but this topic was never discussed later
> on.
>
> I suggest to add a server metadata parameter “require_request_objects” so
> the AS can indicate its policy to clients.
>
> I think the best place to define this parameter would be JAR, if that is
> not possible any longer, we could use a different PAR-specific name and add
> it to PAR.
>
> What do you think?
>
> best regards,
> Torsten.
>
> > On 1. May 2020, at 17:56, Mike Jones <Michael.Jones=
> 40microsoft.com@dmarc.ietf.org> wrote:
> >
> > Works for me.
> >
> >
> >
> > From: OAuth <oauth-bounces@ietf.org> On Behalf Of Torsten Lodderstedt
> > Sent: Friday, May 1, 2020 2:51 AM
> > To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
> > Cc: oauth <oauth@ietf.org>
> > Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?
> >
> >
> >
> > Filip´s proposal works for me.
> >
> >
> >
> > Are there any objections?
> >
> >
> >
> > Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> schrieb am
> Mo. 27. Apr. 2020 um 20:57:
> >
> > 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 <panva.ip@gmail.com> 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=
> 40lodderstedt.net@dmarc.ietf.org> 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@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > 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.
> >
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>