[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: RSA Interop 2005 Guidelines
It would be really nice to have that button or link to clear the cookie. Thanks, Adam Thomas Wisniewski wrote: > Dave, hi. > > Is is also possible for you to place a link on the eAuth Portal site > that would remove the cookie that way as well? It just seems cleaner > (for example if the same user wanted to see the demo with another > IDP). It seems like restarting the browser might appear a bit of a > hack. If no one else thinks this is necessary, that's fine. > > Tom. > > -----Original Message----- > *From:* Ciochon, Robert [mailto:Robert.Ciochon@ca.com] > *Sent:* Friday, January 21, 2005 12:46 PM > *To:* samldemotech > *Subject:* FW: RE: RSA Interop 2005 Guidelines > > >> Date: Fri, 21 Jan 2005 07:42:38 -0500 >> To: "samldemotech" <samldemotech@lists.oasis-open.org> >> From: Dave Silver <dave.silver@enspier.com> >> Subject: RE: RSA Interop 2005 Guidelines >> Cc: "Mark Joynes" <Mark.Joynes@Entrust.com> >> >> >> The E-Auth Portal uses a cookie, but it is not persistent. This >> is for privacy reasons. We recommend that the user start the >> demo by opening a browser, and end the demo by closing the >> browser. If the user forgets to close the browser, the >> presenter can do so before the next demo. Please let us know if >> you have additional questions. >> >> >> At 02:06 PM 1/19/2005, Ciochon, Robert wrote: >> >>> Hi Tom, >>> Thanks for the feedback. Please see my comments below. >>> >>> Everyone, >>> I have flagged a few items that I would like additional feedback >>> on. Please respond or I'll bring them up on the call. >>> >>> Dave Silver or Terry McBride, >>> Would you please address Tom's question below? >>> 14. Section 4.2 (a question for Enspier). It's not clear to me >>> how the eAuth site knows which IDP the user has selected. Are >>> they using persistent cookie? I.e., I'm asking this to >>> understand what can or cannot be done at the SP. I.e,. if we do >>> the eAuth use case for a couple of SPs and then do the logout. >>> Then a new user tries the demo, how does the eAuth portal know >>> this is a new request (i.e., the user is no longer logged on to >>> the intial IDP)? It would seem that the link back to the eAuth >>> site would require a CCID=<idp entity id> parameter much like >>> the one that is sent to the SP. Section 4.2.2 mentions using >>> cookies to avoid propagation (but I don't think this will work). >>> >>> Regards, >>> Bob >>> ------------------------------------------------------------------------ >>> *From:* Thomas Wisniewski [mailto:Thomas.Wisniewski@entrust.com] >>> *Sent:* Wednesday, January 19, 2005 7:18 AM >>> *To:* Ciochon, Robert; samldemotech >>> *Cc:* Mark Joynes >>> *Subject:* RE: RSA Interop 2005 Guidelines >>> >>> Bob, nice job putting this together. Here are some comments on >>> the use cases/guidelines. >>> >>> >>> 1. General question for optional use case: Can we allow users to >>> perform additional federations from an SP. I.e., after the user >>> federates, login in again, and prior to or after they >>> defederate, they can have the capability to re-federate with the >>> defederated IDP or they can have the capability to federate with >>> additional IDPs. Obviously this is something that we would take >>> them thru. Similar to defederation, which is something that >>> might be done after a user leaves the demo site, additional >>> federations could be left up to each vendor. >>> [bobc] I think we are all concerned with introducing too much >>> complexity into the demo scenarios due to limited amount of time >>> we will have with each customer and the amount of time to test >>> and verify each scenario. The optional use case was designed to >>> demonstrate federation clearly and simply. Could someone show >>> more? Sure, the tools are all there. But I would prefer to >>> keep things as simple as possible at this stage. >>> >>> 2. Section 2.1 bullet 5. I'm not sure if this bullet is >>> necessary (i.e., bullet 6 is enough). I.e., the use case is >>> always from a solicited SP AuthnRequest and not initiated at the >>> IDP. >>> [bobc] I'll leave it in. Better too much... >>> >>> 3. Section 2.2 bullet 7. The text says "Initiate a redirect >>> to...". I think you mean to say "Provide a link to..." >>> [bobc] I will change that. >>> >>> 4. Section 2.2 bullet 8. We should discuss, for the federation >>> case, when the user is required to log into the SP. I.e., this >>> can be before the IDP login or after. Are we saying it's up to >>> the SP or does it always have to be after the IDP login. >>> [bobc] We can discuss this further on the call to see what >>> people agree on. >>> >>> 5. End of section 2.2. You added a possible requriement of >>> displaying the xml documents that were exchanged. Do users >>> really want to see this? Also, what are you thoughts on how this >>> is presented (e.g., thru an external screen/log, or on the >>> actual user browser screen)? >>> [bobc] This was a carryover from last year and is up to each >>> vendor if or how they display this. It is basically a trace log >>> to lend some credence to what is being shown. >>> >>> 6. Section 3.1 first sentence. You say four, but I think you >>> mean three (i.e., login, logout, and eAuth). I think that >>> breakdown works the best. I think you should move section 4.2 >>> after the logout discussion so it will be section 4.2. Then >>> change sections 4.3 and 4.4 into 4.2.1 and 4.2.2. Basically >>> following the same format/structure you defined in the summary >>> section 3.1. >>> [bobc] I actually meant SP initiated login, idP initiated login, >>> SP initiated logout and idP initiated logout as the 4 base SAML >>> cases, and then eAuth as a separate 5th case. I'll have a look >>> at the section setups when I update it next time. >>> >>> 7. Section 3.1.3, item 2b. s/on the SP is/on the SP and is/ >>> [bobc] WIll change that. >>> >>> 8. General comment on the optional use case. I beleive the SP >>> should state which name id format it is requesting, i.e., x509 >>> subj name or a persistent id. This is done via the NameIDPolicy >>> element. This implies that the SP site, which lists the IDPs >>> that support persistent identifiers, needs to be smart enough to >>> distinguish between the 2 types of identifiers when calling and >>> IDP. We had said this would be based on the user name. However, >>> if the answer to (4) above is that the user logs into the IDP >>> before the SP, then the SP does not know who the user is and >>> therefore cannot be sure which NameIDPolicy to use. I'm >>> proposing the SP has additional smarts in it (each vendor does >>> this however they want) so that the IDP links on the SP site >>> hare two-fold. There are links for the base case IDPs and links >>> for the optional IDPs. Additionally, the eAuth use case always >>> implies the base case IDPs, hence x509 Ssubject names. Section >>> 6, item 1, wording would be updated accordingly. >>> [bobc] I was heading in that direction myself on the last call >>> when people said they could just figure things out from the user >>> name. Let's discuss this some more on the call today since I >>> think your method will simplify things for the demo staff. >>> >>> 9. Section 3.2, item 4 and 5. I don't believe this requirement >>> was mentioned on any call/email. I.e., obtaining user consent is >>> up to each individual provider. I suppose these could be >>> optional steps but they should not be required. I.e., when a >>> user clicks on the IDP link at the SP, they are consentng to >>> federation. The same goes for section 6 bullet 4. >>> [bobc] I think it was mentioned in passing when discussing this >>> case and was never explicitly called out. I know this was a big >>> deal in the Liberty Alliance specs. Let's discuss on the call. >>> >>> 10. Section 3.2, item 8. s/SP triggering/SP via the IDP >>> triggering/ The idea being the user does another saml login at >>> the IDP by initiating it at the SP (basically a repeat of your >>> item 1). To me it seemed like the text in item 8 is suggesting >>> that perhaps the user logs in at the SP. >>> [bobc] That is more accurate and will be changed. >>> >>> 11. Section 3.2, item 9. s/on the web page/on the SP web page/ >>> [bobc] I will change this. >>> >>> 12. Section 4.1.2, item 3. s/of links to the SP resources/of SP >>> resources/ ^ s//(URLs)/ The text suggest the links (actual >>> URLs) are to the SP site when they are actually urls back to the >>> IDP with some TARGET=xxx or RelayState=xxx query parameter. >>> [bobc] I will change this >>> >>> 13. Section 4.1.2, item 4. s/resource links and/resources and/ >>> [bobc] I will change this. >>> >>> 14. Section 4.2 (a question for Enspier). It's not clear to me >>> how the eAuth site knows which IDP the user has selected. Are >>> they using persistent cookie? I.e., I'm asking this to >>> understand what can or cannot be done at the SP. I.e,. if we do >>> the eAuth use case for a couple of SPs and then do the logout. >>> Then a new user tries the demo, how does the eAuth portal know >>> this is a new request (i.e., the user is no longer logged on to >>> the intial IDP)? It would seem that the link back to the eAuth >>> site would require a CCID=<idp entity id> parameter much like >>> the one that is sent to the SP. Section 4.2.2 mentions using >>> cookies to avoid propagation (but I don't think this will work). >>> [bobc] Moved up for reply. >>> >>> 16. Section 5.1 item 1b. The Saml spec requires subject >>> confirmation data, s/MUST NOT/MUST/ and the data should >>> include recipient, notOnOrAfter, etc..... In general I think >>> you can remove section 3. This is just a restatement of what is >>> mandatory in the saml spec. I.e., similar to saying you need to >>> include an IssuerName, etc.... >>> [bobc] Some carryover from last year's doc. I'll take it out if >>> people find it confusing. >>> >>> 17. Along the lines of S3ction 5.2.1 item 1, an AuthnRequest >>> should either not inlcude an RequestedAuthnContext element or >>> should value this with run:...:Password. >>> [bobc] Anyone else have feedback on this one? It is a carryover >>> as well. >>> >>> 18. Section 5.2.1, item 2 and section 7.1, item 3. Why are >>> there any restrictions at all on SubjectLocality? Shouldn't this >>> just be up to the IDP. >>> [bobc] I gather this was added last year because people had some >>> problems with DNSName. Anyone else have feedback on this one? >>> >>> 19. Section 5.2.2, item 1. Is everyone ok, with the 3 >>> attributes. It seems like using postal address (someone else >>> suggested this attribute at a prior meeting) would add to the >>> personalization features of the demo. >>> [bobc] Anyone else have feedback on this? >>> >>> 20. Section 8.1.1, bullet 1 and 3 AND section 8.1.2 bullet 2. >>> I thought we agreed that there would be one SP resource for each >>> SP and each vendor would only have one IDP. So change the zero >>> or more reference to there is one of these per vendor. Anything >>> beyond one would complicate the eAuth site, the links necessary >>> on each SP/IDP, etc... >>> [bobc] Not every vendor is required to provide both an SP and an >>> idP. As I recall, someone mentioned that last year not all >>> vendors provided both. That is why the zero. I will change >>> the "more" to "one". >>> >>> 21. Section 8.1.1, bullet 3. s/URL to the idp logon page/The >>> SAML entity id of the IDP/ The entity id format is like a url >>> but it is NOT a url and is not meant to be the idp login url. >>> [bobc] I was using the recommendation in the spec, especially >>> since we are only using front channel bindings. I was trying to >>> make it simple, but can change it if it is not accurate for our >>> demos. >>> >>> 22. Section 8.1.2 bullet 3. Actually remove the IDP entity id >>> reference from 8.1.1 and move it here, note that this is a URL >>> but an entity id only. >>> >>> 23. Section 8.1.2 bullet 1. For issuer name, is this a string >>> for display purposes? >>> [bobc] I believe that is how it was used last year. >>> >>> 24. Section 8.1.4. I would say copy the list of vendors into A.2 >>> as well. I.e., store the value for <Vendor> in the appendix so >>> it's easy to retrieve. Also, in A.2 perhaps store the following >>> data point: IDP-Basic, SP-Basic, IDP-Optional, SP-Optional to >>> indicate which vendor is doing what. It would be really helpful >>> to nail this down before the dry run. >>> [bobc] I plan to add that in somehow once I have who is >>> supporting what. >>> >>> 25. Section 8.1.4, I would suggest sticking with the same >>> password convention as the base case. I.e., the password is the >>> same as the userid. It just makes things easier I think. >>> [bobc] Or should we make just one password that is the same for >>> all users for both base and optional? Anyone else have feedback >>> on this? >>> >>> 26. Section 9.2.2 bullet 5 s/qill/will/ >>> [bobc] I will fix that. >>> >>> 27. Section A.2 and 8.1.1. The additional URLs that are necesary >>> (in A.2 and in 8.1.1) include: >>> - SingleSignOnService (at IDP for base and optional case) >>> - AssertionConsumerService (at SP for base and optional case) >>> - SingleLogoutService (request) (at IDP and SP for base and >>> optional case) >>> - SingleLogoutService (response) (at IDP and SP for base and >>> optional case) >>> - ManageNameIDService (request) (at IDP and SP for optional case >>> only) >>> - ManageNameIDService (response) (at IDP and SP for optional >>> case only) >>> [bobc] Will expand those sections >>> >>> 28. Section A.2 and 8.1.2. The additional identifiers that are >>> necessary (in A.2 and in 8.1.2) include: >>> - SP entity id (simliar to idp entity id). >>> - Receiver Name (similar to the idp issuer name). I.e., a >>> display name for the SP. >>> [bobc] Will add receiver name. SP entity id is same question as >>> idP. >>> >>> Tom. >>> >>> -----Original Message----- >>> From: Ciochon, Robert [mailto:Robert.Ciochon@ca.com] >>> Sent: Tuesday, January 18, 2005 3:17 PM >>> To: samldemotech >>> Subject: RSA Interop 2005 Guidelines >>> >>> Hi, >>> Attached is the first cut at defining the guidelines and use >>> cases for the SAML Interop at RSA 2005. Please send me any >>> feedback, questions, clarifications, etc... >>> Regards, >>> Bob >>> <<RSA2005-saml-interop.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]