Skip to content

Read the misconfigured and invalid date creator context outcomes - #189

Merged
jwrosewell merged 1 commit into
mainfrom
feature/51did-context-outcomes
Sep 3, 2026
Merged

Read the misconfigured and invalid date creator context outcomes#189
jwrosewell merged 1 commit into
mainfrom
feature/51did-context-outcomes

Conversation

@jwrosewell

Copy link
Copy Markdown
Contributor

Why

The 51Degrees cloud is gaining two creator context results and a third
factor result. Without this change a client on today's package does not
simply fail to recognise them, it reports something else.

The factor case is the one that matters. A factor of misconfigured says
the service that checked the identifier is not configured to determine that
factor, so it could not have checked it for any request. Every client here
mapped anything that was not the word verified to a mismatch, so a
misconfigured factor would be reported as a replay indicator for something
the identifier says nothing about.

What changed

  • A misconfigured factor value, read on its own so it cannot fall through
    to a mismatch. Everything else that is not verified still becomes a
    mismatch, so an unexpected value never reads as a pass.
  • A misconfigured context value. The service could not complete the check,
    either because it compared nothing or because it compared some factors and
    at least one could not be determined. Nothing a caller sends can produce
    it, so it is a signal about the deployment rather than about the
    identifier. Against 51Degrees public cloud it should not occur. Against a
    self-hosted service it means that service is not reading the client's own
    connection, or is missing an engine it needs.
  • An invaliddate context value. The creation date is one the scheme could
    not have produced, being in the future or before the creator context
    scheme began, so the identifier is fabricated.
  • The existing "could not be checked" value is kept, because it has been
    public since the enumeration was added. Its documentation now says the
    service no longer sends it and which value replaced it in each case.

Both new context values are appended, so no existing value moves.

Verification

Stated per language rather than claimed in general.

  • .NET: builds, and the package tests pass with two new tests, one proving a
    misconfigured factor does not read as a mismatch and that no factor in
    such a response does, the other proving an invalid date is read, carries
    no factor block, and is independent of the signature outcome. One
    unrelated test fails identically on unmodified main, because its
    resource key does not include the fodid.* properties.
  • PHP: php -l clean on both changed files. The enums are string-backed, so
    tryFrom maps the new words with no other change.
  • Node: node --check clean on both changed files.
  • Python: parses, and _factor_of reads the new word explicitly.
  • Java: not compiled, because Maven is not installed on the machine this
    was written on. The change is enum constants and one method body, and it
    needs a build before it is merged.

Related

The cloud side is 51Degrees/cloud PR #304. These packages and that change
have to move together, since a client on an older package misreports the new
values rather than ignoring them.

Produced with AI assistance under James Rosewell's direction and needs human
review.

The cloud is gaining two context results and a third factor result, and
without these a client reports them wrongly rather than not at all.

A factor of "misconfigured" says the checking service is not configured to
determine that factor, so it could not have checked it for any request. It
is not a mismatch, and a client that let it fall through to one would report
a replay indicator for something the identifier says nothing about.

A context of "misconfigured" says the service could not complete the check,
either compared nothing or compared some factors with at least one it could
not determine. A context of "invaliddate" says the creation date is one the
scheme could not have produced, being in the future or before the creator
context began, so the identifier is fabricated rather than anything being
wrong with the service. Neither is reachable by anything a caller sends.

The existing value for a context that could not be checked is kept, because
it has been public since this enumeration was added, and its documentation
now says the service no longer sends it and which value replaced it in each
case. Both new values are added at the end, so no existing value moves.
@jwrosewell
jwrosewell merged commit f7bc649 into main Sep 3, 2026
1 check passed
@jwrosewell
jwrosewell deleted the feature/51did-context-outcomes branch September 3, 2026 13:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant