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
- From: "Ciochon, Robert" <Robert.Ciochon@ca.com>
- To: "Thomas Wisniewski" <Thomas.Wisniewski@entrust.com>,"samldemotech" <samldemotech@lists.oasis-open.org>
- Date: Fri, 21 Jan 2005 13:48:52 -0500
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
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.
<<rsademotech-minutes-2005-01-19.doc>>
Robert Ciochon
eTrust Development Manager
Computer
Associates
San Diego, California
(858) 625-6866
robert.ciochon@ca.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]