[openid-specs-rande] SAML to OIDC mapping specification

[Roland Hedberg]

> On 10 Mar 2021, at 14:10, Mischa Salle <msalle at nikhef.nl> wrote:
> 
> Hi all,
> 
> On Wed, Mar 10, 2021 at 01:50:32PM +0100, Niels van Dijk wrote:
>> Hi,
>> 
>> On 10-03-2021 13:29, Etienne Dysli Metref wrote:
>>> On 09.03.21 13:07, Ivan Kanakarakis wrote:
>>>> I can understand how it is nicer to have a single set of claims, but ..
>>>> if there is no reason to define one form and not the other,
>>>> and the choice is purely aesthetics or convention,
>>>> then why don't we define both forms as equivalent (aliases)
>>>> and thus support the current behaviour of all systems?
>>> Absolutely! :D This gives every side their favourite naming convention.
>>> The specification may become a bit bloated, but I think this would be a
>>> cheap price to pay for this.
>> 
>> I totally dissagree: we will pay dearly for having an ambiguous
>> specification and will pay the price in support cost, additional complexity,
>> implementors making errors, etc.  Also we will have double work each time we
>> want to make a change to the spec. Are we next going to overload all our
>> scopes as well?
>> A specification should be clear, unambiguous and concise. In this case there
>> is no technical need for duplication of claim names, as they serve the exact
>> same use case. whatever 1 format we pick it will do the job. This is
>> unneeded complexity, which once introduced will take a decade to get rid of
>> again, see our may mistakes in SAML.
> 
> I fully agree with Niels. We should absolutely not allow both in one
> spec. It will be confusing, expensive to maintain and expensive on a
> performance level.

Totally agree !!

And by the way, since I love Python I’m in the snake camp :-)

— Roland
Scratch a pessimist and you find often a defender of privilege. -William Beveridge, economist and reformer (5 Mar 1879-1963) 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-rande/attachments/20210310/33bc4864/attachment.html>