First readings from mission control: M7 Identity’s conformance checkpoint
There is a particular pleasure in watching a test campaign produce its first useful results. The console starts telling you something concrete, and the next jobs become easier to see. We have reached that early checkpoint with M7 Identity’s local OpenID Connect conformance work.
Three official-suite checks have passed. There is a configuration warning we can explain, a set of deliberately unsupported cases, and browser-dependent work still waiting to finish. Alongside that, thirteen supplemental local protocol checks passed.
That gives us something worth sharing—and a clear list of work ahead.
What the first checkpoint says
This snapshot was recorded on October 11, 2026 at 19:55 UTC, which is October 12 at 03:55 WITA. It comes from the unchanged OpenID conformance suite, version 5.3.2, running locally against an isolated synthetic provider. It does not measure the production service.
These counts cover 86 selected modules across the chosen plans. Fourteen finished and seven were interrupted, leaving 65 unrun. A module included in two plans counts twice.
Here is the official-module accounting at that checkpoint:
| Result | Modules | Meaning |
|---|---|---|
| Passed | 3 | Logout discovery checks completed successfully |
| Warning | 1 | Discovery configuration completed with a schema warning |
| Skipped | 10 | Unsupported scope or unsigned request-object cases |
| Interrupted | 7 | Browser-dependent work stopped without a verdict |
| Not run | 65 | Selected work that has not been attempted |
The three passes cover discovery for relying-party-initiated, front-channel and back-channel logout. That is useful groundwork: the suite checked the advertised discovery information for those paths. It does not establish that a complete sign-in-and-logout journey works, or that every receiving application clears its session correctly.
The distinction matters to anyone integrating identity. Finding the documented door and successfully walking through the whole building are different tests. We have results for the discovery part; the rest still needs its own evidence.
A warning with a specific explanation
The configuration module recorded 43 successful condition checks, one warning and no failed conditions. The warning concerns two M7 discovery extensions that the suite’s schema does not recognize: m7_orgs_endpoint and m7_acl_introspection_endpoint.
We have kept that warning visible. It is a configuration result with an explanation, rather than another pass to add to the three above. Keeping the original suite and its reporting unchanged makes the checkpoint easier to inspect and compare later.
The ten skips deserve the same care. They concern unsupported scopes and unsigned request-object cases. A skip tells us that the selected case did not run as a supported path. It cannot tell us that the behaviour passed.
The browser work is still open
Seven modules needed browser interaction and ended interrupted, with no suite verdict. Sixty-five selected modules had not run. The recorded campaign has no active runs; those numbers describe unfinished coverage.
An interrupted browser run establishes neither product failure nor success. We need the browser-dependent paths to complete before drawing conclusions about them.
One integration boundary remains especially clear: M7 requires PKCE with S256. Some common authorization requests generated by the suite lacked the required challenge, while the dedicated valid-PKCE requests specified S256. Those generated browser URLs were not visited. We have not relaxed the product requirement, and this checkpoint does not claim that the browser PKCE path has passed.
Separate checks, useful progress
Thirteen supplemental strict local protocol checks also passed. They are additional evidence from our own checks, kept separate from the official-suite module totals. Adding them to the official pass column would make the result less useful.
For builders, that separation helps answer the practical question: which behaviour has evidence, under which test conditions, and what remains unknown?
I’m pleased with this start. We have a recorded local checkpoint, specific discovery successes and an honest account of the unfinished work. The next milestone is to complete the blocked browser paths and report their actual results. Formal certification, production acceptance and a full-plan success claim each require more evidence than this preliminary campaign supplies.
For now, the team has a useful set of readings from the console—and good reason to keep going.