Skip to content

51Degrees Identifier (51Did) Edge Cookie vendor module, registry code 51dd #1072

Description

@jwrosewell

Status note (current checkout 666953a0d): The vendor module and 51dd reservation below are proposals tied to a linked branch. No 51did, 51dd or ec_client_fixed implementation was found in this checkout. Reconfirm the approved module seam, registry and browser-cycle contract before implementation.

This issue tracks the first real vendor Edge Cookie module: the 51Degrees Identifier (51Did) module, registry code 51dd (reserved in provider-code-registry.md).

Shape

  • A vendor crate at crates/edgecookie/<vendor>, named by that folder, injected by the adapter and configured by an [ec.<name>] table that core captures as raw values and never interprets. Core stays vendor-neutral; the module ships nothing into core.
  • The module works client-side by design, through the client-cycle path (Add the client-set Edge Cookie value path #1046): the page script obtains the identifier and posts it to POST /_ts/api/v1/ec/resolve, and the module verifies the payload before minting. This is the general pattern for any solution that supplies a web-browser-unique identifier, whether from a new web platform feature or from a user-installed extension, and the demonstration module (cfix) exists to exercise exactly this round trip.
  • Minted identifiers are 51dd~<value>. Inside the envelope the value format is the module's own, constrained only by the global identifier bounds (at most 256 bytes, alphabet A-Za-z0-9._~-), so binary payloads are carried base64url-encoded (standard base64 uses +/=, which are outside the alphabet).

Acceptance bar

  • Verification of the posted payload measured against the client-cycle spec's retained reservation design (audience binding, expiry, unique id, session binding, replay handling), which the spec keeps verbatim as the bar for the first vendor scheme.
  • The page module performs the live permission check before vendor contact required by the client-cycle spec §4, and is injected only when the module is selected.
  • The verbatim round-trip proof every module owes: mint, cookie, read-back, identity-graph key, and withdrawal, all under the 51dd~ code.
  • A real-browser integration round trip in the browser suite.

Declared interest

This is 51Degrees' own module, filed by 51Degrees. The seam it uses is the same one available to every vendor, and the module adds no vendor code to core, which is the pattern we are asking the project to hold every vendor to.

Done when

  • The approved module registry reserves 51dd, and selected configuration loads the vendor module without adding vendor-specific parsing to core.
  • A real browser exercises the client-cycle path, including permission check before vendor contact and verification/replay rejection of the posted payload.
  • Tests prove mint, cookie read-back, identity-graph key and withdrawal use the 51dd~ namespace and meet the global identifier bounds.
  • The vendor-specific proof and any remaining limitations are documented with the module.

Activity

  1. added theissue type on Oct 1, 2026
  2. changed the issue type fromtoon Oct 1, 2026
  3. changed the title [-]51Degrees Identifier (51Did) Edge Cookie vendor provider, registry code 51dd[/-] [+]51Degrees Identifier (51Did) Edge Cookie vendor module, registry code 51dd[/+] on Oct 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions