[per-carlsson]

Tele2 Play (formerly Com Hem Play) is a streaming TV service operated by Tele2 Sverige AB. User accounts have historically signed in at login-id.comhem.com. We are moving sign-in to a new identity provider at account.tele2play.se. The same accounts and passwords work on both login pages during the migration.

Most existing users have their password saved for comhem.com, so Safari and other password managers don't offer it on account.tele2play.se. These users would have to type the password by hand or look it up in their password manager.

Evidence that the domains are related

TLS certificates. Both login hosts use OV certificates issued to the same organization:

login-id.comhem.com:   subject=C=SE, ST=Stockholms län, O=Tele2 Sverige AB, CN=identity.tele2.com
account.tele2play.se:  subject=C=SE, ST=Stockholms län, O=Tele2 Sverige AB, CN=account.tele2play.se

Apple App Site Association. Both domains list the same Apple Developer team (SW6GH82JCB) and the same app (SW6GH82JCB.se.comhem.app.tivo, Tele2 Play on the App Store):

• https://login-id.comhem.com/.well-known/apple-app-site-association
• https://www.tele2play.se/.well-known/apple-app-site-association

DNS. Both domains are delegated to Tele2's own name servers (*.dns.swip.net, c.dns.tele2.net).

I'm a consultant developing the Tele2 Play iOS/tvOS app on behalf of Tele2 Sverige AB and can confirm the relationship.

Overall Checklist

• I agree to the project's Developer Certificate of Origin
• There are no open pull requests for the same update

for shared-credentials.json

• There's evidence the domains are currently related (SSL certificates, DNS entries, valid links between sites, legal documents etc.)
• One or more of the following:
  • If using shared, the new group serves login pages on each of the included domains, and those login pages accept accounts from the others. (For example, we wouldn't use a shared association from google.co.il to google.com, because google.co.il redirects to accounts.google.com for sign in.)