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
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
Thank you, Justin. Actually, I wanted to see someone write a summary about
what happens in each combination from a viewpoint of both RP and AS with
regard to backward compatibility (as I told you in other channel just
before you posted your email ^_^).
So,
*(1) New Client + New Server*
No problem
For solution [2], this is the behavior that’s required for OIDC today, so I
would say that’s the New Client behaving like an Old Client in order to talk to
an Old Server. So in reality, (2) causes the request to be rejected, and that’s
OK.
I don’t think it’s viable to require parameters to exis
