Re: [security-services] Comment on sstc-saml-glossary-2.0 (also c loses AI #0114)

[Greg Whitehead <grw@trustgenix.com>]

On Mar 13, 2004, at 5:36 AM, Conor P. Cahill wrote:

>
>
> Scott Cantor wrote on 3/12/2004, 7:45 PM:
>>
>> The SP isn't really affected either way, since he can throw the
>> value away even if the IdP does create it. The user obviously
>> is affected and should be able to tell the IdP "yes" or "no". I
>> don't see how putting a value in a request from the SP impacts
>> the user's ability to do this. It seemed to me to be a UI
>> optimization to allow the SP to ask the question and tell
>> the IdP what the user said, which is why I phrased it as a
>> consent distinction.
>
> It's not just that.  It's that you're saying if an SP wants to perrform
> an authentication check they must also initiate a federation whether
> they want to or not.   While I think that many SPs will want to do
> a federation, I think it is very bad to require that behavior in
> the API.
>
> If we're concerned about bytes on the request, then have a parameter
> that indicates whether or not the SP wants to federate and have it
> default to "true" if not specified.
>
> Just to give a bit of history here, I'm the one who pushed Liberty to
> have a combined auth & Fed request because of the optimization of
> doing both in one call.  However I think it is very bad to force
> that behavior.

 From a use-case point of view, I think this capability (to request that  
  a new federation not be created if one doesn't already exist) is most  
useful in combination with passive authentication requests, where the  
idea is to probe for an existing federation in combination with an  
active session. The idea being that, even if an active session exists  
at the IdP, I might want to have users explicitly choose to federate  
with my site if they haven't done so before. Note that this overlaps  
somewhat with the idea of 'consent' in ID-FF.

-Greg

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