What do people think about the idea of applying contract testing to externally standardised APIs such as OIDC? On the one hand, a standard is a standard and so in theory, there is no need for additional use cases to be documented - that’s the purpose of the standard. Additional scrutiny via contract testing could be an additional maintenance burden for little value. On the other, contract tests could still illuminate gaps in implementation and the usual value of contract test (consumer coverage, documentation of usage, prevent breaking changes etc.) (context: we have a customer who is wanting to do it on an implementation of an OIDC system and is wondering about the benefits of such an endeavour)

So….is the concept here ultimately a “do I have the right configuration” type test? When I think of OIDC…I think there are a bunch of libs that do this for me…most of them from IdP’s….so what exactly are we testing here?

Yes, I'm trying to find good reasons to do CDC here. I think config could be tested differently. The claims and grant types available is a bit blurry and could be argued is just config

Based on how I understand CDC…optional things are not part of the contract ya? And all non-standard claims are optional with OIDC/OAuth2/JWT

Well it depends. Usually optional things can be tested, just as a separate example (test)

I see what you mean….IMO they should be tested as part of the service functionality…I can see the gray area…but to me thats dipping into functionality…but I could be convinced otherwise so I definitely get the question

I’m trying to convince myself, with the default position that CDC probably isn’t going to be super appropriate

I think I agree with how you feel. I am interested in what others think though, I tend to stick to “purist” when it comes to such things 🙂

If it's a way to checklist that you're implementing all the OIDC things properly, it could be useful. I don't know if it's better than any existing approaches.

Yeah I'm feeling the same way folks. Thanks for the input!