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] Comment on sstc-saml-glossary-2.0 (also c losesAI #0114)




Scott Cantor wrote on 3/13/2004, 3:21 PM:
 >
 > Exactly what I've been trying to say, thanks. I'm only objecting
 > to this being characterized as a "privacy" issue or some kind of
 > critical control flag for the SP to make the system function
 > properly. It's a UI consideration. It may or may not make sense
 > to actually use the consent flag for this, but that's what it's
 > about.

It is not a consent flag.  It is an *intent* flag.  It is indicating
what the SP's intent of the request is.  It allows an SP to request
an authentication without also requesting a federation.

In some cases, the times and places that a federation will be
requested will be different than the times and places that a
an authentication will be requested.

The two requests are essentially:

    a) if you can, please tell me who the user is
    b) tell me who the user is, if they haven't yet
       established a connection to me, initiate one
       at this time.

Those two statements are very different and the expectation
as to when an SP will do one vs the other are very
different (in many environments).

You may not have such differentiation in your environment, but
that doesn't mean that you should build the protocol so that
it prohibits others from having that distinction.

Conor




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