I think the nature of the backwards incompatibility is important here. The way
that things are now, using merge-with-precedence, you have the following matrix
of compatibility:
New Server | Old Server |
-----------+-------------+--------------+
New Client | YES | NO |
Old Client | YES | YES |
If you ask me, this is the right balance for a breaking change. Old clients,
where the vast majority of the code is, don’t have to change. New clients can
only talk to servers with the new features, which is the ability to drop
parameters from the external request. This would apply to both OIDC and plain
OAuth.
I think we should follow this kind of pattern in the discussions on OAuth 2.1,
which I think JAR should be a part of/
— Justin
> On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki <t...@authlete.com> wrote:
>
> Breaking backward compatibility in this part would mean that OpenID
> Certification given to AS implementations with request_uri support will be
> invalidated once they support JAR. It also would mean that test cases in the
> official conformance suite need to be changed in a backward-incompatible
> manner, which would implicitly encourage that all certified implementations
> should re-try to get certification.
>
> Changing the spec now might need more three to six months, but it would be
> worth considering what we get and lose by saving the months and breaking
> backward compatibility.
>
> Best Regards,
> Taka
>
> On Wed, Dec 18, 2019 at 4:14 PM Nat Sakimura <sakim...@gmail.com
> <mailto:sakim...@gmail.com>> wrote:
> So, no change is OK?
>
> On Wed, Dec 11, 2019 at 10:01 PM John Bradley <ve7...@ve7jtb.com
> <mailto:ve7...@ve7jtb.com>> wrote:
> I also slightly prefer the merge approach.
>
> There are plusses and minuses to both.
>
> Changing again now that it is past ISEG review and backing out a Discuss will
> add another three to six months at this point, if we can get them to agree to
> the change.
>
> John B.
>
> On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura <sakim...@gmail.com
> <mailto:sakim...@gmail.com>> wrote:
> Correct. The WG supported the precedence approach and even merge just like
> OIDC as it is very useful from the implementation point of view and helps
> with a bunch of deployment patter.
>
> The push back came in from the Ben Campbell’s DISCUSS.
> See
> https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-actually-specifies-the
>
> <https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-actually-specifies-the>
>
> I am willing to go either way as long as people agree. My slight preference
> is to the original approach.
>
> Best,
>
> Nat Sakimura
>
> 2019年8月29日(木) 6:56 Brian Campbell
> <bcampbell=40pingidentity.....@dmarc.ietf.org
> <mailto:40pingidentity....@dmarc.ietf.org>>:
> FWIW, as best I can remember the change in question came as I result of
> directorate/IESG review rather than a WG decision/discussion. Which is likely
> why you can't find the "why" anywhere in the mailing list archive.
>
> On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan <panva...@gmail.com
> <mailto:panva...@gmail.com>> wrote:
> Well it kind of blows, doesn't it? I wasn't able to find the "why" anywhere
> in the mailing list archive around the time this was changed.
>
> My take on satisfying both worlds looks like this
>
> - allow just JAR - no other params when possible.
> (which btw isn't possible to do with request_uri when enforcing client
> based uri whitelist and the jwsreq 5.2.2 shows as much)
> - enforce the "dupe behaviours" defined in OIDC (if response_type or
> client_id is in request object it must either be missing or the same in
> regular request).
> - allows merging request object and regular parameters with request object
> taking precedence since it is a very useful feature when having pre-signed
> request object that's not one time use and clients using it wish to vary
> state/nonce per-request.
>
> I wish the group reconsidered making this breaking change from OIDC's take on
> request objects - allow combination of parameters from the request object
> with ones from regular parameters (if not present in request object).
>
> S pozdravem,
> Filip Skokan
>
>
> On Wed, 28 Aug 2019 at 23:02, Brian Campbell <bcampb...@pingidentity.com
> <mailto:bcampb...@pingidentity.com>> wrote:
> Filip, for better or worse, I believe your assessment of the situation is
> correct. I know of one AS that didn't choose which of the two to follow but
> rather implemented a bit of a hybrid where it basically ignores everything
> outside of the request object per JAR but also checks for and enforces the
> presence and value of the few regular parameters (client_id, response_type)
> that OIDC mandates.
>
> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan <panva...@gmail.com
> <mailto:panva...@gmail.com>> wrote:
> Hello everyone,
>
> in an earlier thread I've posed the following question that might have gotten
> missed, this might have consequences for the existing implementations of
> Request Objects in OIDC implementations - its making pure JAR requests
> incompatible with OIDC Core implementations.
>
> draft 14 of jwsreq (JAR) introduced this language
>
> The client MAY send the parameters included in the request object
> duplicated in the query parameters as well for the backward
> compatibility etc. However, the authorization server supporting this
> specification MUST only use the parameters included in the request
> object.
>
> Server MUST only use the parameters in the Request Object even if the
> same parameter is provided in the query parameter. The Authorization
>
> The client MAY send the parameters included in the request object
> duplicated in the query parameters as well for the backward
> compatibility etc. However, the authorization server supporting this
> specification MUST only use the parameters included in the request
> object..
>
> Nat, John, everyone - does this mean a JAR compliant AS ignores everything
> outside of the request object while OIDC Request Object one merges the two
> with the ones in the request object being used over ones that are sent in
> clear? The OIDC language also includes sections which make sure that some
> required arguments are still passed outside of the request object with the
> same value to make sure the request is "valid" OAuth 2.0 request (client_id,
> response_type), something which an example in the JAR spec does not do. Not
> having this language means that existing authorization request pipelines
> can't simply be extended with e.g. a middleware, they need to branch their
> codepaths.
>
> Is an AS required to choose which of the two it follows?
>
> Thank you for clarifying this in advance. I think if either the behaviour is
> the same as in OIDC or different this should be called out in the language to
> avoid confusion, especially since this already exists in OIDC and likely
> isn't going to be read in isolation, especially because the Request Object is
> even called out to be already in place in OIDC in the JAR draft.
>
> Best,
> Filip
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
> <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.
>
> 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 <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
> <https://www.ietf.org/mailman/listinfo/oauth>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/ <http://nat.sakimura.org/>
> @_nat_en
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
> <https://www.ietf.org/mailman/listinfo/oauth>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/ <http://nat.sakimura.org/>
> @_nat_en
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
> <https://www.ietf.org/mailman/listinfo/oauth>
> _______________________________________________
> 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
