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

[Torsten Lodderstedt]

I‘ve never really understood what the benefit of space separated strings for claims representation is (or the OAuth scope parameter). So +1 in favor of array

FYI: we are kicking off the new WG for identity assurance next week. The kickoff call will take place on 18th. This WG will also be a place to discuss claims/claim mappings.

best,
Torsten.

> Am 15.12.2019 um 10:02 schrieb Mischa Sallé <msalle at nikhef.nl>:
> 
> +1 for an array, prevents problems with spaces inside the values.
> 
> concerning the "where to discuss", I guess either openid-specs-ab or openid-specs-rande, which of the two depends on the claims.
> 
> Cheers
> Mischa
> 
>> On 14 December 2019 14:23:11 CET, Roland Hedberg <roland at catalogix.se> wrote:
>> 
>> 
>>> 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) 
> 
> -- 
> Nikhef                         Room H155
> Science Park 105      Tel. +31-205925102
> 1098 XG Amsterdam
> The Netherlands
> -- 
> openid-specs-rande mailing list
> openid-specs-rande at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-rande