Yes that is what it comes down to. Is that a feature having a fixed set of parameters in the signed JAR and some number of OAuth parameters unsigned outside the JAR, that people want badly enough for us to pull the spec back and restart IESG review.
I think Torsten is speculating that is not a feature people use. It was a feature that people on the IESG objected to. If we can get concensus in the WG to pull it back, we can do it. That is the decision we should make. John B. On Fri, Jan 10, 2020, 12:01 PM Justin Richer <jric...@mit.edu> wrote: > 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> > wrote: > >> >> >> Am 06.01.2020 um 23:50 schrieb John Bradley <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
