Claims mapping and custom claims

The Issue

The email claim we get isn't really an email. When I use GitHub SSO or Passkey, I get stuff like john@github or john@passkey, which breaks a bunch of things:

• can't correlate these fake emails with actual users
• apps obviously can't email someone@github
• same person could end up with different "emails" depending on how they log in

I know this probably comes from how Tailscale itself handles non-email auth methods, but it makes TS-IDP tricky to use in practice.

What I've Tried

I see people are putting proxies in front of TS-IDP to do claims transformation, which works, but that adds unnecessary complexity. tsidp is a perfect fit for small teams and communities, and that is precisely where there are no unified SSO domain, or strict username rules, etc.

Also tried using extraClaims based on the code and related issue, but can't get it to work, no matter what I tried. This would at least let me hardcode something like preferred_username per-user right into the policy -- not great, but good enough workaround:

{
  "src": ["john@passkey"],
  "dst": ["..."],
  "app": {
    "tailscale.com/cap/tsidp": [
      {
        // [the usual options...]

        "includeInUserInfo": true,
        "extraClaims": {
          "preferred_username": "john.doe",
        },
      },
    ],
  },
}

I have tried this with the tsidp build off the original tailscale/tailscale repo, as well as with this repo's release 0.0.1 and 0.0.2 -- where I had to fight the new CAP policy first -- and eventually had some other problems, having to revert back to the tailscale/tailscale code.

Thoughts?

Would be awesome if we could do something like:

• claims mapping directly in the policy (map john@github → actual useful info)
• get extraClaims actually working (am I doing it wrong?)
• maybe add some other useful claims that don't depend on having real emails?

Anyone else hitting this? Any workarounds I'm missing? Or is the proxy approach just the way to go for now?

The issue does not name files, tests, or a specific entry point. Start by tracing how tsidp derives OIDC claims and handles the policy's extraClaims option, then compare behavior for GitHub SSO, Passkey, and ordinary email identities. Done would require an agreed claims-mapping design and tests covering the resulting user and email claims.