Treating a remembered session as email verification

[rafageist]

The flow only shows the browser still holds issuer cookies; it does not prove the user now controls the mailbox. It could be reused for any attribute tied to that session, so calling it email verification overstates what is proved:

• Old, stolen, or shared sessions can mint SD-JWTs without mailbox access.
• The assurance differs from normal email or OIDC checks; weaker than proving possession of the inbox.
• DNS trust is not defined (no DNSSEC or signed metadata), which lets an attacker point to a fake issuer.
• Privacy risk: issuer and DNS can correlate attempts through referrer, origin, and timing.
• Cookie and CORS fragility: it leans on SameSite=None; Secure and permissive policies; many environments block or partition this.
• Threat model gaps: no replay or exp/jti guidance, no revocation or reauthentication, and a 60 second iat window is both tight for clock skew and still open to replay.
• Key handling is vague: the browser key should be non exportable and hardware anchored; keeping it in JS or localStorage breaks the binding.

Recommendations:

• For proof of mailbox control, use a delivery challenge, an OIDC/OAuth flow with consent, or a fresh user authentication step (for example WebAuthn) instead of ambient cookies.
• If DNS delegation stays, require authenticated retrieval (DNSSEC or signed metadata), define TTL and rotation, and fail closed on unauthenticated answers.
• Clarify cookie and CORS requirements and ask for user reauthentication for higher risk use, especially on shared devices.
• Add explicit anti replay controls (exp, jti, nonce binding) and revocation guidance; allow realistic clock skew.
• Document privacy controls (referrer and origin handling, retention at issuer) and state the remaining correlation risks.
• Rename or reframe this as an issuer session assertion unless mailbox possession is actually proven.