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)

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

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).

Only being able to specify the required attributes on an authnrequest out-of-band through an AttributeConsumingServiceIndex is a limitation of the current SAML version. I am sure this was the only right choice back in 2005.

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.

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

============

<complexType name="AuthnRequestType">
    <complexContent>
    <extension base="samlp:RequestAbstractType">
        <sequence>
            <element ref="saml:Subject" minOccurs="0"/>
            *<element ref="saml:Attribute" minOccurs="0" maxOccurs="unbounded"/>*
            <element ref="samlp:NameIDPolicy" minOccurs="0"/>
            <element ref="saml:Conditions" minOccurs="0"/>
            <element ref="samlp:RequestedAuthnContext" minOccurs="0"/>
            <element ref="samlp:Scoping" minOccurs="0"/>
        </sequence>
        <attribute name="ForceAuthn" type="boolean" use="optional"/>
        <attribute name="IsPassive" type="boolean" use="optional"/>
        <attribute name="ProtocolBinding" type="anyURI" use="optional"/>
        <attribute name="AssertionConsumerServiceIndex" type="unsignedShort" use="optional"/>
        <attribute name="AssertionConsumerServiceURL" type="anyURI" use="optional"/>
        <attribute name="AttributeConsumingServiceIndex" type="unsignedShort" use="optional"/>
        <attribute name="ProviderName" type="string" use="optional"/>
    </extension>
    </complexContent>
</complexType>

============

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 8:29 PM, Cantor, Scott <cantor.2@osu.edu> wrote:

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

>
>The requirement to request attributes over a front end channel (either to
>facilitate consent or to allow for user interaction) if one that I
>encounter more often. A possible direction is to combine an AuthnRequest
>and AttributeQuery in one by extending
> AuthnRequestType with the zero or more <saml:Attribute>.

The reason the Extensions element was created in the schema was because
extending message types has no real benefit when it comes to getting off
the shelf code to work. If you have implementations that don't have any
customizability with respect to Extensions, that's basically a functional
limitation that has to be addressed if the code base has any hope of
longevity. OTOH, expecting SSO logic to handle arbitrary message types is
not realistic in practice.

So that's why a dedicated mechanism for extension of *existing* message
semantics was created.

TL,DR; extending AuthnRequest in the XML sense is a non-starter.

-- Scott

security-services message