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....@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....@dmarc.ietf.org> wrote: > > > > Works for me. > > > > > > > > From: OAuth <oauth-boun...@ietf.org> On Behalf Of Torsten Lodderstedt > > Sent: Friday, May 1, 2020 2:51 AM > > To: Brian Campbell <bcampbell=40pingidentity....@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....@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...@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....@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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
