Next in thread → Next in month →

RE: RSA SAML Interop 2005 Conference Call Minutes - Jan 19 2005

From
Ciochon, Robert <>
Date
2005-01-21T18:48:56+00:00
ID
Thread
RE: RSA SAML Interop 2005 Conference Call Minutes - Jan 19 2005
Title: RSA SAML Interop 2005 Conference Call Minutes - Jan 19 2005

Hi Tom,

Thanks for the feedback.  You are correct for the 
first item, it should have been section 3.2, second item 1, and I 
meant going to the SP first, not logging into it first.  So for the 
optional use case scenario, the user starts by going to an SP, selects an idP 
from the list that supports the optional use case, logs into the idP and then 
logs into the SP to complete the federation.  Sorry about the 
mistakes.

 

Regarding the second comment, the point I was trying to get 
across was we would not decide which scenario was being done based on an 
overloaded element.  In the actual optional use case scenario, I guess the 
only list we would need is the optional use case idP's.  On a previous 
call, someone mentioned then going to a second optional use case SP, which is 
where I got the idea that a list of optional use case SP's might be needed as 
well.  Again, sorry for the confusion.

Regards,

Bob

From: Thomas Wisniewski 
[mailto:] 
Sent: Friday, January 21, 2005 
6:13 AM
To: Ciochon, Robert; samldemotech
Subject: RE: RSA 
SAML Interop 2005 Conference Call Minutes - Jan 19 2005

Bob, a 
couple of comments...

 

Regarding your comments on section 3.2 item 8. I think that either the 
section is wrong or your comments are incorrect. Item 8 in section 3.2 talks 
about the step of doing another login after the federation. So there should be 
no contention on this. The idea is that the user federated their identify 
between the SP and IDP (so they had to login in to the IDP and then SP to 
complete this). Now that they logged out (item 7), they should be able to do the 
use case again (i.e., item 1). However, this time after they go thru the steps 
(and log in at the IDP), they will notice that they do NOT need to log in at the 
SP (i.e., the federation has worked).

 

The 
oen item we discussed, which pertains to whether a user logs into the SP or IDP 
first, is in terms of the federation use case. I.e., to start federation 
(assuming the user is at the SP screen), should the user log into the SP first 
and selects and IDP to federate with, then they log into the IDP. Or should 
the flow be: log into the IDP first, then the SP. Most were saying the IDP log 
in should be first. I believe Adam was proposing the SP first. It would be 
simpler if we just used one flow. Personally it does not matter to 
me.

 

Regarding your comments on Section 6, item 3. I would suggest that we 
have only ONE starting point for the optional case. I.e., you start at the SP 
only. Your comment suggests that we can start at the IDP as well. I.e., send an 
unsolicited <Response> for federation. What do others think? If we do this 
as well, the guidelines will need to be updated to reflect this. As of now, it 
implied an SP only starting point. If we only start from the SP, then the IDP 
(after a user logs in) would only have a single list of SPs (for the base case). 
Thoughts?

 

 

Tom.

  
-----Original Message-----
From: Ciochon, Robert 
  [mailto:]
Sent: Thursday, January 20, 2005 8:35 
  PM
To: samldemotech
Subject: RSA SAML Interop 2005 
  Conference Call Minutes - Jan 19 2005

  
<<rsademotech-minutes-2005-01-19.doc>> 

  
Robert Ciochon 
eTrust Development Manager 
Computer 
  Associates 
San Diego, California 
  
(858) 625-6866 
Next in thread → Next in month →