[openid-specs-rande] SAML to OIDC mapping and value types

[Roland Hedberg]

> On 13 Dec 2019, at 17:41, Christos Kanellopoulos <christos.kanellopoulos at geant.org> wrote:
> 
> Hello folks,
> 
> This week at TechEx, Ivan and I spent some time on an issue we had been seeing on SATOSA, namely that all claims returned from the SATOSA OP had single values even if the SATOSA internal representation of the attribute has multiple values.
> 
> Upon further investigation and discussion with Mike Jones we realised that there is not just one way to represent multi-value claims in OIDC. As a matter of fact each claim should have its own specification of that what claim value should be.
> 
> In the OIDC core specification:
> 
> all claims (except amr in the ID token) are single valued.
> 
> Three claims (given_name, family_name, middle_name) have the following description:
> 
> Note that in some cultures, people can have multiple given names; all can be present, with the names being separated by space characters.
> 
> Two claims (mail_verified, phone_number_verified) are booleans
> 
> updated_at is a number
> 
> address is JSON object
> 
> amr is JSON array of strings
> 
> everything else is string
> 
> The point of this e-mail, is that in the R&E id_token and userinfo endpoint claims <https://docs.google.com/document/d/1FQcZEUsjRjVxR5X5uii_Ma9adFIe9ER3b4WE-wYo7hU/edit#> along with the mappings we need to describe what the type of each claim value is.
> 
> So for example, eduPersonScopedAffiliation is a multi-value attribute in the eduPerson schema. Should we represent it as a JSON array or as space separated string (I hope you all say the former) when mapped to OIDC.
> 

I’m definitely in favour of JSON array.
I’ve always thought space separated string an abomination :-)

— Roland
Can anything be sadder than work left unfinished? Yes, work never begun. -Christina Rossetti, poet (5 Dec 1830-1894) 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-rande/attachments/20191214/4362673e/attachment.html>