Clarify RP action when encountering invalid OP EC

[malmgren01DF]

In the conformance tests, there is one proposed test in the RP Automatic Registration section that says

RP rejects OP EC with errors: RP runs all validation rules on OP EC (per first section of tests), rejecting invalid ones

Going through the spec, I failed to find some wording that would clarify what the RP should do if it wants to do automatic registration with an OP, but the OP EC does not validate in some respect. I guess it could be generalized to the question of what a federation participant should do when it encounters an invalid EC. Let's say, for example, that the OPs EC sub is incorrect and not equal to the iss, should there be a statement in the the spec along the lines of "further interaction with the federation entity MUST NOT be attempted", or is this implicit somehow?

[teamktown]

Observation: from a trust evaluation standpoint, i agree it's an implicit security best practice to be failling closed, ie. no trust exists.

Is the 'must not be attempted' part @malmgren01DF you said meant to imply 'don't attempt to retry indefinitely' as a way to poll/await for the EC to recover thus preventing inadvertent DDOS or poor network behaviour that needs to be specified in the spec?

[malmgren01DF]

@teamktown In my original comment, I wasn't really thinking about retry behavior or so. I think what I tried to say was that, in the case of explicit client registration, 12.2.1 says

The RP MUST perform Trust Chain and metadata resolution for the OP, [...]. If the resolution is not successful, the RP MUST abort the request.

So in that case, assuming a manually built trust chain, the spec is clear that the RP must abort.

For automatic registration, there is no such clear language. There is, subjectively, "an aura of intent" that the RP must not continue, but it's not spelled out.

The concrete case where this came up was that I wrote a conformance test that acts as an OP that publishes a deliberately invalid EC and then, if its authorization endpoint is invoked, the test fails. When conformance tests fail, we add a link to the spec section that backs up the behavior and in this case I couldn't find any.