+1 for require_request_objects AS metadata parameter. The natural place for this parameter for me would be the JAR spec .
Vladimir On 12/05/2020 09:27, Torsten Lodderstedt 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 -- Vladimir Dzhuvinov
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth