Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

[John Bradley <[e-mail]>]

I haven't seen any real use of merge.   It happens with Connect as a side
effect of OAuths current requirement to have some of the parameters outside
the JAR.

Nothing stops servers from ignoring parameters outside JAR or acting on
query parameters outside the JAR if they are not in the OAuth registry.   A
server can merge but that would not be JAR compliant if they care.

If the AS returned an error for parameters values that differ between the
JAR and the query that is not required but I don't think that is
prohibited.  I need to look at that.

JAR dosen't say your server can't do something else, but that is not JAR.

Clients should be updated to have all the parameters in the JAR.  That
should be the case for most of not all clients now.

For older servers they need to continue to include the required OAuth
parameters outside.

Servers need to migrate and eventually move to returning a warning or error
when a registry parameter is outside the JAR if JAR is used.

Especially if PAR is used (I suspect that will become the prefers pattern)
then merging won't really make sense.

John B.

On Tue, Jan 7, 2020, 6:19 AM Torsten Lodderstedt <[e-mail]>
wrote:

>
>
> Am 06.01.2020 um 23:50 schrieb John Bradley <[e-mail]>:
>
> A client could duplicate those outside the request object for some sort of
> backwards compatability but they will be ignored.
>
> Is this used for backward compatibility with the OIDC servers?
>
> What we have lost is the merge capability.  There are some use cases that
> could use that to have a presigned object that some paramaters like state
> are outside.
>
>
> Is this option used in the wild? As far as I understand the main use case
> is a 3rd party signing the request object that way entitling the client for
> something. I‘m asking since in my experience any kind of entitlement by a
> 3rd party is handled behind the scene using registries.
>