[WIP] SAML to OIDC mapping specification

[edysli]

Here is my proposal to start specifying mappings from SAML attributes to OIDC claims, based on our (SWITCH) experience of running one identity provider for both protocols.

[msalle]

Hi Etienne,
short remark on the name change (although I'm not saying one is better than the other):
that was inspired by the other registered JWT claim names (see https://www.iana.org/assignments/jwt/jwt.xml) which are all either short or "snake_case". I don't remember the exact details, but at some point the whitepaper moved from the (original) camelCase to snake_case which seems more consistent with each protocol's semantics. Going the other direction is then also more logical and intuitive. For example if at some point a SAML equivalent of let's say email_verified would need to be introduced, it would become emailVerified.

[surfnet-niels]

Hi Etienne,

By definition it is not possible to have the SAML friendly name match one-on-one as OIDC does not support casing in the claim names, so edupersonPrincipalName would need map to edupersonprincipalname. I fear we can discuss endlessly if that is more beautiful and/or more understandable as compared to eduperson_principal_name. While indeed there is a extra underscore in the names I very much doubt anybody will misinterpret the intent of e.g. eduperson_principal_name. We simply followed what seems to be the 'norm' in the IANA JWT registry: https://www.iana.org/assignments/jwt/jwt.xml

However, since the document[2] was written, many have adopted the proposal which means there are now multiple production instances (including e.g. eduTEAMs, PERUN, SURF/Openconext) who use this specification. I very much doubt they will be willing to change there production platform and all connected RPs because of a few underscores.

Best,

Niels

[edysli]

Hi Niels,

Thanks for dropping by to comment! :) I was wondering whether you were still around to provide insight into that choice.

By definition it is not possible to have the SAML friendly name match one-on-one as OIDC does not support casing in the claim names, so edupersonPrincipalName would need map to edupersonprincipalname.

I'm afraid you're wrong on that one. The OpenID Connect Core 1.0 specification states:

5.2. Claims Languages and Scripts
[...]
Since Claim Names are case sensitive, [...]

Granted, this piece of information is a bit hidden (I think it should be featured a the top of section 5). The same about scope names is much clearer though:

5.4. Requesting Claims using Scope Values
[...]
Multiple scope values MAY be used by creating a space delimited, case sensitive list of ASCII scope values.

Moreover, the JWT RFC clearly specifies that claims names are case sensitive:

10.1.1. Registration Template

Claim Name:
The name requested (e.g., "iss"). Because a core goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short -- that is, not to exceed 8 characters without a compelling reason to do so. This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception.

So there is nothing holding us back to only lowercase names.

While indeed there is a extra underscore in the names I very much doubt anybody will misinterpret the intent of e.g. eduperson_principal_name.

Indeed, that isn't very risky. It is, however, a needless complexity when one already has SAML attributes and a name transformation is required between the two worlds.

However, since the document[2] was written, many have adopted the proposal which means there are now multiple production instances (including e.g. eduTEAMs, PERUN, SURF/Openconext) who use this specification. I very much doubt they will be willing to change there production platform and all connected RPs because of a few underscores.

That is unfortunate inertia, based on something that isn't a specification (as you yourself wrote in that document) so early implementers run the risk of having things specified a different way. Is this working group required to follow that earlier white paper?

[edysli]

Withdrawing this proposal as we reached consensus on using snake_case for claim names.