Should SAML->RT->ID-JAG flow suggest or require the `email` scope?

[aaronpk]

Currently the spec says the client MUST request the openid offline_access scopes when exchanging the SAML assertion for refresh token.

It is likely, but not guaranteed, that the SAML assertion that the client has would already include the email address. (SAML can be configured to return opaque values for the NameId, and there is no guarantee the IdP would be configured to send an email attribute.)

If the SAML assertion did not have the email, you could argue the client should request the email scope because the ID-JAG will be visible to the client and would contain information beyond what is in the SAML assertion.

However, the purpose of including the email in the ID-JAG is for the benefit of the Resource AS, when it looks up users by email address from the SAML assertion. This behavior isn't necessarily known by the client, since it's about the relationship between the Resource AS and IdP.

So the question is whether we want to keep the text as is with the email claim being optional, or aim for better interoperability by suggesting/requiring that the client request the email scope.

Also note that if the IdP includes the sub_id property with the SAML NameId values, then the Resource AS likely won't need to rely on the email claim at all.

[mcguinness]

This seems related to #99 and #83. The lack of interop mechanism for a client to know what claims and needed and how to request them. I don't think it makes sense to make email claim required as it's deployment specific. Same with requiring a client to request email scope. Its perfectly valid for a deployment to only use sub and sub_id and not email.

The IdP AS isn't limited to minting claims in the ID-JAG that were only present in the subject_token. Why can't the IdP AS make the decision to always send the email claim to a given RAS?

[aaronpk]

The IdP AS isn't limited to minting claims in the ID-JAG that were only present in the subject_token.

Technically true, my thought there was along the privacy lines. If the client doesn't request email, but the IdP returns email in the ID-JAG, the client learns more than needed about the user. It's not really a concern in the enterprise scenario, but could be in the consumer scenarios. Maybe it doesn't matter because if the IdP is concerned about revealing info to the client it should always just not return that info even if the client requested it.

[mcguinness]

I would prefer to keep this as deployment-specific for now and support something more generic for claims requests with #83. I also think we should make it clear that JWE could be used by encrypting ID-JAG with RAS public key to address privacy concerns similar to ID-Token. There many be other claims besides email that are PII and may need encryption for some deployments.

[mcguinness]

PR #102 for optional JWE support