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] Comments on SAML 2.0 Core draft-19...


> -----Original Message-----
> From: Conor P. Cahill [mailto:concahill@aol.com] 
> Sent: Tuesday, August 10, 2004 07:08 AM
> To: Nick Ragouzis
> Cc: 'Scott Cantor'; 'SAML'
> Subject: RE: [security-services] Comments on SAML 2.0 Core draft-19...
> Nick Ragouzis wrote on 8/10/2004, 9:45 AM:
>  > +0 (whatever experienced implementers think), ...
>  >
>  > ... but consider that verbosity (less-of) is not the only
>  > criteria in a case such as this, where user interfaces
>  > are concerned.
> Actually, verbosity is a significant issue with the
> AuthNRequest, 


> but yes, it isn't the only issue.


>  > Here the schema is also conveying a sense of the "default"
>  > user interaction principles ... and those follow interaction
>  > design practices that no unbeckoned presentations suddenly
>  > appear [1].
> I disagree.  The schema should represent typical usage and
> not anything about UI principals.

Well, this attribute is only about user interfaces.

>  > I'd say that in the security context this user interface
>  > aspect extends to all services cooperating in a consistent,
>  > integral, presentation. Which imposes a default of: don't
>  > interpose yourself (IdP/ECP) unless I specifically say you
>  > may (and by which I am indicating that I have already given
>  > the user the proper indications and am committing to follow
>  > up 'your' interactions appropriately).
> Again, I disagree.  Even from a security context, having the
> default be that when the SP queries the IDP and the IdP can't
> ask the user about it, you're potentially opening at least a
> privacy hole.

Hum. not my reading ... an IDP must establish the identity
of the principal. If policy requires direct interaction,
then IsPassive=0 is required.

> The majority of the time, when an SP says to the IdP, Hey,
> I need you to give me an authentication assertion, the SP
> will want the IdP to interact with the user so that the
> IdP can query the user for credentials, if necessary.

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

> If the SP doesn't want the interaction, it should positively
> indicate it as such because there are privacy considerations
> involved in probing for access without interacting with a
> user.

This runs both ways, it seems to me. So then we're back to
the ostensible domain of the attribute, which is user 
interaction ... barring decisive overriding considerations,
of course.
[I note that John Linn agrees with you too, Conor.]


> Conor

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