Capture a real assertion emitted by the legacy laddr emergence-slack code in production, and diff against the assertion the new IdP would emit for the same user.
Surfaced by the saml-idp plan's closeout (PR #49). Per plans/saml-idp.md#risks--unknowns, this is "the single highest-stakes thing in this plan" — the v1 IdP claims to preserve NameID stability for every existing Slack account through cutover. The way to actually prove that is:
- Browser-side: capture a laddr-emitted SAMLResponse during a real /Slack/Login flow (browser devtools → Network tab → look at the POST to slack.com/sso/saml — the SAMLResponse is in the form body, base64-encoded)
- Decode the XML
- For the same Person, build the v1 IdP's response (via /api/saml/slack/launch) and decode
- Diff field-by-field. Acceptable diffs: timestamps, IDs. Unacceptable: NameID.Value, NameID.Format, NameQualifier, SPNameQualifier, attribute names.
If the diff turns up a NameID delta for any user, we need to fix migration before cutover.
Out of band of the v1 PR; needs:
- Access to a logged-in legacy laddr account
- Coordination with that user
Capture a real assertion emitted by the legacy laddr emergence-slack code in production, and diff against the assertion the new IdP would emit for the same user.
Surfaced by the saml-idp plan's closeout (PR #49). Per plans/saml-idp.md#risks--unknowns, this is "the single highest-stakes thing in this plan" — the v1 IdP claims to preserve NameID stability for every existing Slack account through cutover. The way to actually prove that is:
If the diff turns up a NameID delta for any user, we need to fix migration before cutover.
Out of band of the v1 PR; needs: