3 ms·

I agree that the service provider shouldn't expect the SAML identifier to be an email. I suspect that the SUNetId is something readable (based on the human's na

I agree that the service provider shouldn't expect the SAML identifier to be an email. I suspect that the SUNetId is something readable (based on the human's name) as opposed to a fully opaque alphanumeric string ? On the other hand, having emails (or namespaced identifiers that look like emails but aren't) does provide a nice way to start the login process from the service provider's login page, as opposed to having to start from the IdP side, since the service provider can infer which IdP to use based on the identifier's namespace.

CaliforniaKarl 7y ago
>I agree that the service provider shouldn't expect the SAML identifier to be an email. I suspect that the SUNetId is something readable (based on the human's name) as opposed to a fully opaque alphanumeric string ? Yup. For those curious, you can find Stanford's list of released-by-default attributes here: https://uit.stanford.edu/service/saml/arp https://uit.stanford.edu/service/saml/arp >On the other hand, having emails (or namespaced identifiers that look like emails but aren't) does provide a nice way to start the login process from the service provider's login page, as opposed to having to start from the IdP side, since the service provider can infer which IdP to use based on the identifier's namespace. Yup, totally agree, and that's one of the annoying things about SAML. In Stanford's case, that's the eduPersonPrincipalName attribute.