[openid-specs-rande] Feedback on SAML-to-OIDC mapping

[Mischa Salle]

Hi Paul,

On Thu, Feb 25, 2021 at 11:19:31AM +0100, Paul Millar wrote:
> 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.

first of all, thanks for bringing this up! I think it is indeed a good
thing to mention somewhere.
The high priority thing at the moment (originating from the same
whitepaper) is to get a good document providing input for the R&Sv2
discussion, see the meeting notes of the last meeting
https://github.com/daserzw/oidc-edu-wg/blob/master/meeting_notes.md#20210218 
with (referenced) google doc
https://docs.google.com/document/d/1FQcZEUsjRjVxR5X5uii_Ma9adFIe9ER3b4WE-wYo7hU
(next meeting will be coming Monday at 15:00 CET).

Cheers,
Mischa

> 
> 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)
> > 
> -- 
> openid-specs-rande mailing list
> openid-specs-rande at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-rande

-- 
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email msalle at nikhef.nl
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..