OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]