[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]