# M7 Identity conformance reconciliation — 15 October 2026 **Status: local assessment, fully triaged; current-source validation remains incomplete.** All 86 selected case identities have a recorded outcome or next decision. The owner-workflow tally is **58 passed or owner-dispositioned, 16 queued or deferred, 2 narrow claim-contract questions open, and 10 skipped**. The 58 comprises **41 recorded technical passes, 9 presentation acceptances and 8 warning dispositions**. It does not mean 58 official protocol passes. Read the [progress article](https://m7.org/news/lab/post/m7-identity-conformance-reconciliation-2026-10-15) for the short account. This dated technical page explains the evidence, arithmetic, decision boundaries and remaining work. For integration behavior, use the [provider profile](https://m7.org/docs/api/sso.user.m7.org/provider-profile.md) and [SSO reference](https://m7.org/docs/api/sso.user.m7.org/README.md). ## Scope and method The assessment used the OpenID Foundation conformance suite, pinned to version 5.3.2, in an isolated local environment with disposable synthetic identities. The selected plans covered provider configuration, Basic OpenID Provider, Form Post Basic OpenID Provider, RP-initiated logout, front-channel logout and back-channel logout. These are selected local cases, not a claim to cover every certification profile, signing algorithm, client type or M7 capability. The 15 October reconciliation assigns one owner-workflow bucket to each original identity, C01 through C86. Earlier attempts and their grades are retained. A later focused result supersedes an earlier result only within its matching case and source/configuration epoch; it does not silently turn a local source check into an official suite result. Fixture and harness issues, presentation review, standards interpretation and product findings are considered separately. The underlying records include the case matrix, dated source reviews, warning-component decisions, exact retained-image acceptances, design acceptances carried forward, implementation reviews and deferred-work notes. This page publishes a curated summary and exact case membership. It excludes raw requests, credentials, session material and private operational evidence. **No completed official case has been established on the latest source epoch.** The recorded results span dated epochs and are inherited at the current source boundary. No full official sweep of the current code, production acceptance, formal certification or provider-wide full pass is claimed. Supplemental local checks remain a separate evidence class. ## Three different counts These views answer different questions. None changes another view's grades. | View | Counts across the same 86 identities | Meaning | | --- | --- | --- | | Reconciled owner workflow | 58 passed or dispositioned; 16 queued/deferred; 2 narrow questions; 10 skipped | Decisions and next actions, including presentation and extension dispositions. | | Recorded technical coverage | 41 PASS; 19 WARNING; 14 REVIEW; 10 SKIP; 2 DEFERRED | Preserves incomplete POST coverage as deferred rather than calling it a pass. | | Latest retained completed raw grades | 41 PASS; 20 WARNING; 14 REVIEW; 10 SKIP; 1 FAILED | Preserves the last completed historical grade for each identity, including the incomplete POST cases. | C36 retains a raw FAILED grade and C71 a raw WARNING grade. Both have incomplete, owner-deferred POST coverage, explaining the difference between the latter two rows. Neither becomes an additional current-code failure or a pass through reconciliation. A skip contributes no positive coverage. All 14 historical REVIEW cases have been handled in the owner workflow: seven exact retained-image acceptances, two earlier design acceptances and five locally implemented/reviewed logout cases awaiting their deferred final visual run. All 19 exercised warning cases have been triaged; C02 and C37 retain a narrowly scoped undecided claim-contract question. ## Exact case ledger Every identity appears once in this table. The first three rows total 58; the five deferred rows total 16. Case labels are stable assessment references, not public session or test-instance identifiers. | Owner-workflow bucket | Count | Original case identities | | --- | ---: | --- | | Recorded technical PASS | 41 | C03, C12, C14, C15, C17, C18, C20, C21, C22, C23, C25, C27, C28, C29, C31, C32, C33, C34, C35, C38, C47, C49, C50, C52, C53, C55, C56, C57, C58, C60, C62, C63, C64, C66, C67, C68, C69, C70, C72, C83, C85 | | Owner presentation acceptance or design carry-forward | 9 | C24, C26, C59, C61, C78, C79, C81, C10, C45 | | Whole-case warning disposition recorded | 8 | C01, C09, C11, C44, C46, C73, C80, C84 | | Logout UX implemented/reviewed; final visual run deferred | 5 | C74, C75, C76, C77, C82 | | Assurance and name/profile decisions deferred | 6 | C19, C54, C13, C48, C30, C65 | | Replay repair implemented; future local retest queued | 2 | C16, C51 | | Mixed warning; TLS metadata review queued last | 1 | C86 | | POST coverage incomplete and deferred | 2 | C36, C71 | | Narrow extra-claim contract questions open | 2 | C02, C37 | | Skipped coverage | 10 | C04, C05, C06, C07, C08, C39, C40, C41, C42, C43 | | **Total** | **86** | **86 distinct identities** | ## Presentation decisions and local logout work The owner accepted the exact retained images for C24, C26, C59, C61, C78, C79 and C81. C10 and C45 carry forward an earlier redirect-presentation design acceptance; they are not new image approvals. These nine dispositions leave the historical official REVIEW grades intact and do not establish fresh current-code browser behavior. C74, C75, C76, C77 and C82 have a simpler logout-message design and sanitized trace logging implemented and locally reviewed. The associated nine files remain uncommitted and undeployed at this checkpoint. Fresh final browser captures and the matching visual/official rerun are deferred. Some retained images show obsolete automatic-fallback behavior, so they cannot verify the new implementation. This publication does not make those changes live. ## Warning dispositions and remaining questions ### Discovery extensions — C01 The suite's schema did not recognize `m7_orgs_endpoint` and `m7_acl_introspection_endpoint`. The owner accepts these documented public metadata extensions. Standard endpoint metadata remains present; these fields describe capabilities rather than account records or credentials. Additional metadata is allowed by [RFC 8414 section 2](https://www.rfc-editor.org/rfc/rfc8414.html#section-2). This disposition is not a new endpoint-authorization audit or an official PASS. ### Additional authorization-error detail — seven whole cases and part of C86 C09, C11, C44, C46, C73, C80 and C84 retain a qualified intentional-extension disposition for reviewed `error_reason` paths. The reviewed pairs are `login_required` with `session_required` and `invalid_request` with `response_type_required`. They add detail alongside standard errors; they do not replace them. The bounded review found no concrete sensitive account detail or unsafe reflection in these reviewed branches. It does not establish a universal allowlist or absence of other disclosure risks. [OpenID Connect Core section 3.1.2.6](https://openid.net/specs/openid-connect-core-1_0.html#AuthError) says additional authorization-error parameters SHOULD NOT be returned. That conflict is recorded and deferred. No informed waiver, strict-profile clearance, registration or general interoperability claim is asserted. The private-extension disposition is therefore narrower than strict standards compliance. [RFC 6749 section 8.2](https://www.rfc-editor.org/rfc/rfc6749.html#section-8.2) describes the endpoint-parameter extension process. C86 has the same qualified disposition for its error-detail component, but two TLS-observation warnings remain open. It is counted once in the deferred TLS bucket. There are eight whole-case warning dispositions, not nine. ### Extra ID-token claim contract — C02 and C37 The remaining question concerns the precise meaning and intended client contract of `rlm`, `pty` and `id`, including naming and compatibility. M7 intentionally provides global identity. Cross-application recognition alone is not classified as a defect or a requirement to adopt pairwise identifiers. The retained observations establish neither private-key disclosure nor a demonstrated vulnerability. No identifier removal or migration has been selected. These two cases remain open for a bounded contract decision. ### Name and profile data — C13, C48, C30 and C65 C13/C48 concern an omitted requested essential `name`; C30/C65 concern a partial profile response. Requested fields, granted scopes, consent and available authorized data still need comparison. M7 uses a display name and does not require separate first and last names. Reported name/avatar delivery in integrations also needs to be reconciled with the retained requests. There is no confirmed general profile-mapping failure. No name-splitting feature or blanket profile patch has been selected. The deferred review must distinguish absent data from an available, authorized value that a particular contract required. See [OIDC Core section 5.5.1](https://openid.net/specs/openid-connect-core-1_0.html#IndividualClaimsRequests) for the claims-request rules. ### Authentication assurance — C19 and C54 The retained requests supplied `acr_values` and the ID tokens omitted `acr`. Supported assurance semantics and policy remain undecided and deferred. Realm/principal context must not be invented as an assurance class. These cases do not establish insecurity or an MFA release requirement. Voluntary `acr_values` and an essential `acr` request have different rules; see [OIDC Core section 5.5.1.1](https://openid.net/specs/openid-connect-core-1_0.html#acrSemantics). ### Authorization-code replay validation — C16 and C51 The historical cases denied code reuse, but the earlier access token still received a successful UserInfo response. [RFC 6749 section 4.1.2](https://www.rfc-editor.org/rfc/rfc6749.html#section-4.1.2) requires denial of reuse and recommends revoking tokens previously issued from that code when possible. The retained warning concerns the latter behavior; it does not show that reused codes were accepted. A receipt/family-revocation repair exists. Source checks and isolated MariaDB, concurrency and strict-TLS handler checks passed as supplemental validation. Signed-token end-to-end validation remains incomplete and platform-blocked; exact target MySQL compatibility is unverified. Enrollment remains default off. Future local retesting is queued after other fixes, with the platform block and transport checks preserved. No matching current official clearance or deployed repair is claimed. ### Incoming TLS observations — C86 The suite lacked incoming protocol/cipher metadata behind the proxy, including `x-ssl-protocol` and `x-ssl-cipher`. That is an observation gap, not a finding of weak or absent TLS. A harness/proxy limitation is a working hypothesis, not an established cause. This review is queued last and should inspect the harness and trusted proxy first. No production test is authorized by this checkpoint, and verification must not bypass TLS protections. ### Incomplete POST coverage — C36 and C71 These identities retain their historical raw grades while POST coverage is parked as incomplete and owner-deferred. No provider-wide cause, full POST clearance or current-code PASS is inferred. ## What happens next 1. Complete the deferred fresh logout captures and matching checks in a later authorized local session, on an identified source/configuration epoch. 2. Revalidate the existing replay repair after other fixes, when the signed flow's platform prerequisite is resolved; preserve default-off enrollment and verify exact database compatibility before broader claims. 3. Resolve the narrow extra-claim contract questions. Resume the deferred assurance and name/profile comparisons when their policy/data inputs are available, without treating undecided features as proven defects. 4. Resume the two incomplete POST cases under their separately scoped plan. 5. Inspect TLS observability in the harness/proxy last. Any later production investigation requires its own scope and authorization. 6. Before a current-release conformance claim, complete the applicable unchanged official cases on the intended source/configuration, preserve historical evidence and record the remaining warnings, reviews and skips. Documentation publication is separate from product deployment, replay activation and certification. The useful result today is a complete decision ledger with explicit validation limits, not a rewritten full-pass score. ## Evidence provenance This publication reflects the owner-workflow reconciliation recorded on 15 October 2026 at 15:13 UTC, together with the maintained case matrix, warning dispositions, deferred-conflict record, campaign checklist and replay validation stages. Earlier progress reports describe earlier checkpoints; their totals must not be substituted for this reconciliation. The maintained assessment source filenames are `owner-workflow-reconciliation-20261015.md`, `warning-owner-dispositions-20261015.md`, `warning-conflicts-deferred-20261015.md`, and the reconciled case matrices. They are provenance labels rather than links to private evidence. This public summary includes no raw tokens, cookies, customer information, private task links or operational paths. Public references: [OpenID Foundation conformance suite](https://gitlab.com/openid/conformance-suite), [OpenID Connect Core](https://openid.net/specs/openid-connect-core-1_0.html), [OAuth 2.0](https://www.rfc-editor.org/rfc/rfc6749.html), [authorization-server metadata](https://www.rfc-editor.org/rfc/rfc8414.html), and the [M7 provider profile](https://m7.org/docs/api/sso.user.m7.org/provider-profile.md).