OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

samldemotech message

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

Subject: 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.

From: Thomas Wisniewski [mailto:Thomas.Wisniewski@entrust.com]
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?
-----Original Message-----
From: Ciochon, Robert [mailto:Robert.Ciochon@ca.com]
Sent: Thursday, January 20, 2005 8:35 PM
To: samldemotech
Subject: RSA SAML Interop 2005 Conference Call Minutes - Jan 19 2005


Robert Ciochon
eTrust Development Manager
Computer Associates
San Diego, California
(858) 625-6866

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