[openid-specs-rande] Feedback on SAML-to-OIDC mapping
Paul Millar
paul.millar at desy.de
Thu Feb 25 10:19:31 UTC 2021
Hi Roland,
Thanks for the feedback.
In my case, I tried to follow Postel's principle, so the code would
accept either value format: JSON-String or JSON-Array-of-JSON-Strings.
The main purpose for sending the email was to suggest that any future
version of this document (or similar document) include some section,
however short, describing how values are to be encoded.
Cheers,
Paul.
On 24/02/2021 16:43, Roland Hedberg wrote:
> I think you can safely assume that most OIDC/OAuth2 implementations will
> have absolute no clue as to
> what eduperson_entitlement is and what kind of values it holds.
>
> They will probably know about attributes like email because that’s in
> the OIDC core document list of standard
> attributes. Anything outside that list will be unknown territory.
>
> This means that anything goes. To the OIDC software it will not matter
> if it’s a single string or a list of strings.
> It will just accept it and hope that someone higher up will know what to
> do with it.
>
> So for the application that uses the OIDC software it’s a whole other
> ball game. It will know about eduperson_entitlement
> and if so MUST be able to deal with getting a string or a list of string
> as values of the attribute.
> But since you are in control of the application/application software
> that shouldn’t be a problem.
>
> As an aside the OIDC implementation I know about all accept a string or
> a list of strings when the value of an attribute is
> defined to be an array of strings.So your example with ‘aud' is in my
> experience not a problem.
>
>> On 24 Feb 2021, at 12:14, Paul Millar <paul.millar at desy.de
>> <mailto:paul.millar at desy.de>> wrote:
>>
>> Hi,
>>
>> I'm writing here because Niels van Dijk suggested this might be the
>> correct forum to record this information.
>>
>> I was looking at the white paper on how to map SAML attributes to OIDC
>> claims:
>>
>> https://daasi.de/pub/20181011-OIDC-WP.pdf
>> <https://daasi.de/pub/20181011-OIDC-WP.pdf>
>>
>> One thing I noticed was that, under the "Advanced profile" section,
>> the above document describes how an attribute's _name_ is mapped to a
>> corresponding OIDC claim name, but doesn't seem to describe how an
>> attribute's _value_ is mapped.
>>
>> My particular interest was in understanding how eduPersonEntitlement
>> was being mapped to "eduperson_entitlement" claim. In particular, if
>> the IdP assertion contains only one eduPersonEntitlement attribute
>> would a JSON String (rather than a JSON Array of JSON String) be valid?
>>
>> As a concrete example, would this be a valid response from the
>> user-info endpoint:
>>
>> {
>> "sub": "00112233445566778899aabbccddeeff",
>> "eduperson_entitlement": "urn:example.org
>> <http://example.org>:foo",
>> ...
>> }
>>
>> or must it always be represented as a JSON Array:
>>
>>
>> {
>> "sub": "00112233445566778899aabbccddeeff",
>> "eduperson_entitlement": [
>> "urn:example.org <http://example.org>:foo"
>> ],
>> ...
>> }
>>
>> As motivation, there are other OIDC claims that have a
>> string-or-array-of-strings value; e.g., in RFC7519 "aud" claim value
>> is defined as an array of StringOrURI values, but the value MAY be a
>> single JSON-String if the audience is single-valued.
>>
>> I understand that the working group that came up with the white paper
>> is no longer operating; however, I wanted to give some feedback about
>> a potential ambiguity so that other REFEDS groups might consider this
>> in any future version of this (or similar) document.
>>
>> Cheers,
>> Paul.
>> --
>> openid-specs-rande mailing list
>> openid-specs-rande at lists.openid.net
>> <mailto:openid-specs-rande at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-rande
>
> — Roland
>
> Were it left to me to decide whether we should have a government
> without newspapers, or newspapers without a government, I should not
> hesitate a moment to prefer the latter. -Thomas Jefferson, third US
> president, architect, and author (1743-1826)
>
More information about the openid-specs-rande
mailing list