You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue tracks the first real vendor Edge Cookie provider: the 51Degrees Identifier (51Did) provider, registry code 51dd (reserved in provider-code-registry.md).
Shape
A vendor crate under crates/edgecookie/, injected by the adapter, configured by an [ec.providers.51did]-style block that core captures as raw values and never interprets. Core stays vendor-neutral; the provider ships nothing into core.
The provider 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 provider 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 demo provider (cfix) exists to exercise exactly this round trip.
Minted identifiers are 51dd~<value>. Inside the envelope the value format is the provider'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 provider is selected.
The verbatim round-trip proof every provider 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 provider, filed by 51Degrees. The seam it uses is the same one available to every vendor, and the provider adds no vendor code to core, which is the pattern we are asking the project to hold every vendor to.
Produced with AI assistance under James Rosewell's direction; reviewed before filing.
This issue tracks the first real vendor Edge Cookie provider: the 51Degrees Identifier (51Did) provider, registry code
51dd(reserved in provider-code-registry.md).Shape
crates/edgecookie/, injected by the adapter, configured by an[ec.providers.51did]-style block that core captures as raw values and never interprets. Core stays vendor-neutral; the provider ships nothing into core.POST /_ts/api/v1/ec/resolve, and the provider 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 demo provider (cfix) exists to exercise exactly this round trip.51dd~<value>. Inside the envelope the value format is the provider's own, constrained only by the global identifier bounds (at most 256 bytes, alphabetA-Za-z0-9._~-), so binary payloads are carried base64url-encoded (standard base64 uses+/=, which are outside the alphabet).Acceptance bar
51dd~code.Declared interest
This is 51Degrees' own provider, filed by 51Degrees. The seam it uses is the same one available to every vendor, and the provider adds no vendor code to core, which is the pattern we are asking the project to hold every vendor to.
Produced with AI assistance under James Rosewell's direction; reviewed before filing.