M7 Identity conformance: a clearer account of the work ahead
A test report becomes more useful when you can tell which lines need another run, which need a product decision, and which already have an answer. That is the progress in the October 15 reconciliation of M7 Identity’s local conformance assessment: all 86 cases now have an explicit place in the work plan.
The encouraging part is the clarity. We have 41 recorded technical passes, documented presentation and warning decisions, and a bounded account of what still needs validation. Those are different kinds of evidence, and we are keeping them different.
Our preliminary checkpoint, published October 12 WITA, described the early discovery results and unfinished browser work. It remains a dated account of that stage. This follow-up explains the later reconciliation, rather than replacing the old snapshot or presenting every decision as another test pass.
One case, one place in the plan
The October 15 review separates the 86 cases into mutually exclusive groups:
| Workflow status | Cases |
|---|---|
| Recorded technical passes | 41 |
| Historical visual acceptance or design carried forward | 9 |
| Whole-case warning dispositions recorded | 8 |
| Queued or deferred work | 16 |
| Narrow extra-claim contract questions still open | 2 |
| Skipped coverage | 10 |
The first three rows total 58 passed or dispositioned cases. That is an accounting of test evidence and decisions, not 58 official PASS results. Accepting a presentation design does not change a protocol grade. Recording how to handle a warning does not erase the warning. Skips remain skipped.
This table also differs from the retained raw grades. Incomplete POST coverage is deferred here; one of those cases retains a FAILED raw grade. Deferral does not promote it to a pass. The technical report keeps the original results and their history alongside the workflow decisions.
There is another essential limit: all 86 results are inherited across dated source revisions. No completed official case is established on the latest source revision. This is a reconciled historical assessment, not a fresh sweep of current code, a production acceptance result or formal certification.
Decisions can move work forward without changing grades
The nine presentation dispositions cover seven approvals of retained images and two earlier design acceptances carried forward. They tell us which presentation decisions have been made. They do not claim new screenshots of current code.
The warning decisions have similarly specific boundaries. Discovery-extension acceptance is separate from seven whole-case dispositions involving the extra error_reason response parameter. Those seven retain a real standards qualification: OpenID Connect recommends against additional authorization error-response parameters. That conflict remains recorded and deferred; those dispositions do not resolve the conflict or establish strict-profile clearance.
One further case mixes an error-parameter decision with unresolved TLS metadata observations. It stays in the deferred group, counted once. Accepting one component does not settle the whole case.
That is useful discipline for anyone building against an identity service. A documented private extension can explain a result, while its compatibility and standards questions still deserve an explicit answer.
What remains, and what those questions mean
The sixteen queued or deferred cases include logout presentation validation, authentication-assurance and profile-data decisions, replay-repair validation, incomplete POST coverage and a TLS metadata review.
The logout UX changes are local, uncommitted and undeployed, with a fresh final visual run still deferred. The replay repair has isolated supplemental checks, but signed-token end-to-end validation and matching official clearance remain incomplete. Neither is a live-fix announcement.
For profile and assurance questions, the next useful step is to establish the intended contract and compare it with the authorized data and actual request. An omitted profile value does not by itself prove a general mapping defect. An assurance question does not create an automatic requirement to launch an MFA feature.
The TLS observation concerns missing information in the test setup; it does not demonstrate insecure transport. The planned review starts with the harness and proxy observations.
The two residual claim questions are narrower still: what particular extra identity fields mean and what clients should rely on. Global identity and recognition across applications are intentional in M7. These questions establish neither a requirement to switch to pairwise identifiers nor a private-key disclosure or demonstrated vulnerability.
A better starting point for the next run
The October 15 technical reconciliation carries the case membership, original grades, qualifications and deferred rationale. This article gives the working map; that report supplies the detail.
I’m pleased that the review now tells us what each result needs. The next work is to clarify the remaining client contracts and complete the deferred validation, preserving the distinction between local progress and fresh official evidence. A clearer ledger gives the team something practical to act on—and gives integrators a more honest account of where we stand.