But merge gives us the ability, which has been stated here before, to have a fixed core set of parameters inside the JAR and a mixed set of variable parameters outside the JAR.
What if by “merge” we really mean “you can’t repeat things in both places but you can have fields in either”. — Justin > On Jan 10, 2020, at 9:49 AM, John Bradley <ve7...@ve7jtb.com> wrote: > > 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 <tors...@lodderstedt.net > <mailto:tors...@lodderstedt.net>> wrote: > > >> Am 06.01.2020 um 23:50 schrieb John Bradley <ve7...@ve7jtb.com >> <mailto:ve7...@ve7jtb.com>>: >> >> 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. > _______________________________________________ > 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
