Re: [security-services] Comments on SAML 2.0 Core draft-19...

[Greg Whitehead <grw@trustgenix.com>]

I have a vague recollection that there was a reasonably logical  
argument for having the default be 'passive'.

I'm not sure, but I think it might have been that folks thought it was  
best to do a passive "is the user authenticated" probe using a redirect  
(GET) rather than a POST, and so we wanted to be sure that a passive  
AuthnRequest URL encoding wouldn't overrun the URL size limit.

-Greg

On Aug 10, 2004, at 7:59 AM, Scott Cantor wrote:

>>> I disagree.  The schema should represent typical usage and
>>> not anything about UI principals.
>>
>> Well, this attribute is only about user interfaces.
>
> Right, but what's the "common" user interface? In SSO applications (of  
> which
> Liberty use cases are just a subset, if you don't mind my saying), the
> common UI is you redirect from the resource to a login page. People  
> "get"
> this, it's not a new concept on the web.
>
>> Hum. not my reading ... an IDP must establish the identity
>> of the principal. If policy requires direct interaction,
>> then IsPassive=0 is required.
>
> In most cases, IsPassive=1 means that the user had better already be
> authenticated. That's not a common presumption in these systems, so  
> using it
> is really for cases where an SP would *like* the user to maybe get  
> logged
> in, but doesn't really need it yet, seems to me.
>
>> Okay, then a majority of the time the SP is saying: "I've
>> taken pains to set this up with the user." In terms of security,
>> this is testiment that "I (the SP) have done what is to be
>> expected (for this context) to prevent the user from
>> responding to an interposed redirection and etc."
>
> On the web, this seems impossible to me. The spoofing/phishing attacks  
> are
> plentiful and moderately unstoppable without steps that have little to  
> do
> with SAML. We could spend hours on it, but it's immaterial here.
>
> The only question should be "what's the common case, for whatever  
> reason?".
> I think it's false.
>
> -- Scott
>
>
> To unsubscribe from this mailing list (and be removed from the roster  
> of the OASIS TC), go to  
> http://www.oasis-open.org/apps/org/workgroup/security-services/ 
> members/leave_workgroup.php.