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 <https://bitbucket.org/openid/connect/issues/1045/signalling-that-a-request-object-must>), 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
