To expand on this from a non-US perspective, the advice to join a federation also applies to working with universities elsewhere. Having joined one federation

To expand on this from a non-US perspective, the advice to join a federation also applies to working with universities elsewhere. Having joined one federation (e.g. InCommon or the UK Access Management Federation (https://www.ukfederation.org.uk/) https://www.ukfederation.org.uk/)), you can then get your metadata published in eduGAIN (https://edugain.org/ https://edugain.org/) for institutions elsewhere in the world to use. Other things to note from a HE perspective: - Most potential users will likely be using Shibboleth as an IdP, as opposed to ADFS, Ping Federate, Okta and the like. This means that using federation-supplied metadata is far easer to work with than setting up per-SP metadata manually. (In ADFS at least, all the relying party setup is fairly manual, although Powershell can make this slightly less painful.) - The admins running the IdP will most likely not not be the people buying or using the services provided by an SP. This can complicate setting up SAML integrations. - SPs should try to support standard LDAP attribute schemas like the eduPerson (https://wiki.refeds.org/display/STAN/eduPerson https://wiki.refeds.org/display/STAN/eduPerson) schema. These are likely to appear as "urn:oid:..." attributes in the SAML assertion. My personal suggestion for mixed HE/enterprise SPs would be to map both the eduPerson URNs and the equivalent ADFS claim identifiers to one internal identifier. - As noted elsewhere, email addresses as identifiers are problematic in the general case: people change names, people change departments, and people may have multiple email addresses. The eduPersonPrincipalName attribute is generally more stable and is still non-opaque.