Re: [security-services] Re: Dutch eID Preso follow up. RE: Proposed Minu

Subject: Re: [security-services] Re: Dutch eID Preso follow up. RE: Proposed Minutes for SSTC Call (Nov 25, 2014)

Thank you Scott for sharing where you are coming from. That is very helpful. I understand what you mean and see the rational for the extensions element.

If I look at the use cases presented by Colin, Ian and Michiel I see very simular usecases that are now solved in different ways within the boundaries of what the xsd permits (= anything goes with respect to the extensions element). Moreover, European eIDAS may introduce other requirements as well.

If we can find a common ground, the involved countries want this to be part of the formal SAML specification (albeit an optional profile) to stimulate out-of-the-box support from vendors. OASIS should be supporting this. Can you please advise on how to proceed?

NB 'nobody to do it' is an issue that can be addressed.

Met vriendelijke groet,

drs. Martijn Kaag

tel +31 (0) 88 01 20 222 | gsm +31 (0) 6 42 94 00 93 | skype martijn.kaag-connectis

On Wed, Dec 10, 2014 at 9:30 PM, Cantor, Scott <cantor.2@osu.edu> wrote:

On 12/10/14, 8:15 PM, "Martijn Kaag" <martijn.kaag@connectis.nl> wrote:

>I am not sure on your position on this request. Are you suggesting to use
>the extensions element?

Yes. There is no other viable option unless you're literally going to just
redefine the protocol and fork everybody's code. I definitely would not
implement it and if I was eventually pushed to support the feature, I
would do the Extension myself at that point. I'm not going to fork again,
we already did that when we moved from 1.1 to 2.0.

>Current off-the-shelf implementations do not support this use case. As
>such we can only hope that future off-the-shelf implementations will
>work. IMO therefore the extensions element is not the way to proceed (at
>least not for a permanent solution).

That's exactly the way to proceed, that's what it's for. Extending an
AuthnRequest breaks the existing profile and most existing code. The
extension model for adding behavior to existing profiles and protocols is
the Extensions element. It's not about "temporary" or "permanent", it's
just an extension point in the message. It's the alternative to trying to
extend the XML, which we had ample experience with (see below).

>However, this choice should be reconsider for modern times. The number of
>(possible) attributes has increased and the attributes form the basis for
>("claims" based) access control decisions. The latest (European) privacy
>requirements dictate we should never ask for more data except the data
>required to fulfil the current transaction. Also, users are required to
>provide consent.

I'm not saying don't do it, I'm just describing how to go about extending
existing profiles in this kind of way.

>My suggestion is to alter the AuthnRequestType as below and to define a
>new profile to facilitate this usecase in the next SAML version.

I don't expect a new version, but if it did hapen it would not break
existing messages or extend them, it would define extension content using
the extensibility model in the standard.

We looked deeply at this issue when I worked on the Liberty specs in the
later stages, and they followed this exact approach of trying to extend
SAML messages to add content. It doesn't work well, and it doesn't impact
code the way people naively think it does. That's what led to the
dedicated Extensions elements to give implementers a way to recognize and
process extensions at the SAML layer without having to constantly fork
code to handle new messages and break all the existing spec language.

But I guess to put the point to it, if you're coming at this from the idea
that there's going to be a 2.1, it's just not happening. There's nobody to
do it. So if that makes it more palatable to use the Extensions element,
that's as good a reason as any.

-- Scott

security-services message