[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Minutes: SSTC Conference Call (September 22nd, 2009)
I want to address the comments to the SAML Name Identifier protocol contribution as given during the previous SS TC conf call. This is the corresponding part of the minutes of the Sept 22 SS TC call plus my comments in <CG> ... </CG>: ***************************************************************** (ii) SAML Name Identifier protocol proposal (Thinh Nguyenphu/NSN) http://www.oasis-open.org/committees/download.php/34221/SAML%20Name%20Identifier%20Protocol.ppt Christian Günther from Munich, Germany gave the above presentation SC: Why not just use federated login and persistent identifiers? <CG> The question is: who does the federation? Basically, there are three solutions: Let ID_SP, ID_IDP and ID_SAML stand for identifiers of a User that identify this User at a SP, at an IDP, and on SAML protocol level (ie, an identifier shared between the SP and the IDP). Solution 1: The SP does the federation / the IDP does not create an ID_SAML for the User The SP asks the IDP to authenticate the User, the IDP authenticates the User by means of ID_IDP and responds ID_IDP to the SP. Now, the SP has to look into his database to see, which User has ID_IDP for his ID_SP, and stores ID_SP = ID_IDP. That's, for example, how OpenID works. You tell every SP that you are john.doe@nsn.com and all SPs verify this at the IDP of nsn.com. Then they store that user-ID 3234284 (= ID_SP)is john.doe@nsn.com. Disadvantages: - SP has to do the federation, ie, the SP has to implement the mapping. - User gets traceable across services offered by the SP (privacy issue). Solution 2: The SP does the federation / the IDP creates an ID_SAML for the User The SP asks the IDP to authenticate the User, the IDP authenticates the User by means of ID_IDP and then creates (or reads if already created) an ID_SAML and responds this to the SP. Still, the SP has to find out which User has ID_SAML. Nevertheless, for each SP, you can have a different ID_SAML. Disadvantages: - SP has to do the federation. - Delegation (eg, vacation replacement): having to set up a delegation in each different SP separately is similar inconvenient as not having a SSO. Hence, a central point of policy management and enforcement is important. Solution 3: The IDP does the federation The SP asks the IDP to authenticate the User, the IDP authenticates the User by means of ID_IDP and then responds ID_SP. The SP won't have to care about ID_SAML and ID_IDP, because the IDP does the "translation". Advantage: - There is a central point of policy management and enforcement, namely, the IDP, who does the federation. - The User can have more than one account at the SP. The IDP stores these multiple accounts and offers a selection to the User. This is not possible, in case the SP does the federation. If, in case of Solution 3, the IDP does not know the User's ID_SP, then the IDP needs to send a corresponding request to the SP, who then sends ID_SP back to the IDP. This is exactly what the SAML Name Identifier protocol aims to provide. </CG> RP: We have customers who have requested bulk import of identifiers from IdP to SP (and in one case, from SP to IdP). <CG> In the proposed Name Identifier Protocol, it's the IdP who can request a name identifier from a SP in case the IdP receives an AuthnRequest from the SP with a name identifier unknown to the IdP for that SP. Bulk import of identifiers is a completely different thing. Our proposal does not at all intend to prevent SPs from bulk import of identifiers into IdP databases (or vice versa). Maybe, you have misunderstood our proposal in this regard. </CG> SC: (re second bullet on slide 3) Not clear why you need anything more than Web Browser SSO. Why does the SP send an identifier in this case? <CG> Web SSO is and was an important contribution of the SAML standard. However, the service and IDP landscape has changed so that no longer one IDP provides SSO for different (dependent) SPs, but SPs may select the IDP on a per user basis. To phrase it stronger: the privacy-conscious user may want to choose to be federated or not to be included in a potential federation. Furthermore, we are not going to restrict SSO to Web applications. </CG> *********************************************************************** Christian Guenther | NSN COO RTP IE Wireline, Service Delivery and Multimedia -----Original Message----- From: trscavo@gmail.com [mailto:trscavo@gmail.com] On Behalf Of ext Tom Scavo Sent: Thursday, September 24, 2009 12:36 AM To: OASIS SSTC Subject: [security-services] Minutes: SSTC Conference Call (September 22nd, 2009) > Proposed Agenda SSTC Conference Call > September 22nd, 2009, 12:00pm ET Thomas Hardjono presiding > Dial in info: +1 408-774-4073 > Conference code: 4480739 > Password: 72657265 (SAMLSAML) > > 1. Roll Call & Agenda Review Anil Saldhana took the Roll Call. [insert Roll Call results here] Aliases used below: TS = Scavo, Tom RP = Philpott, Rob BM = Morgan, Mr Bob AB = Barbir, Abbie HL = Lockhart, Hal DD = DeCouteau, Duane SC = Cantor, Scott NK = Klingenstein, Mr. Nathan PM = Madsen, Paul FH = Hirsch, Mr. Frederick AS = Saldhana, Mr. Anil TH = Hardjono, Mr. Thomas New Action Items - Port the SSTC Work Summary to the wiki [HL] - Create new Working Drafts of the HoK Profiles [TS] - Produce CD version of Identity Assurance profile and update the wiki [BM] - Produce CD version of Condition for Delegation Restriction [SC] - Investigate and report on CARML. [HL] - Produce CS version of Text-based Challenge/Response profile [AS] - Include the question whether or not to increase the frequency of meetings [TH] > 2. Need a volunteer to take minutes TS volunteered to take minutes > 3. Approval of minutes from last meeting (25 August 2009): > http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200908/msg00083.html RP moves to accept the minutes, BM seconds. Motion carries unanimously. > 4. AIs & progress update on current work-items: > > (a) Current electronic ballots: none SAML Status Presentation for the ITU-T AB asked HL for a SAML update to be presented to the ITU-T. (There's a formal arrangement between OASIS and ITU-T such that the latter normally reviews and adopts OASIS Standards.) HL prepared a presentation: http://www.oasis-open.org/committees/download.php/34320/SAML%20Status%20for%20ITU-T.ppt AB will actually make the presentation to ITU-T. As a by-product, HL produced a work summary for the SSTC: http://www.oasis-open.org/committees/download.php/34321/Post%20SAML%202.0%20Profiles.doc Should this be included in the wiki? If so, at what level of visibility? > (b) Status of past (closed) ballots: > > XSPA - spec has been submitted to OASIS for approval as Full Standard. DD reports that the profile has been submitted to OASIS tc-admin for OASIS Standard ballot. The familiarization period is anticipated to begin on Oct 1, 2009. DD also reports that both wikis have been updated. > SAML V2.0 Attribute Extensions Version 1.0 > SAML V2.0 Metadata Extension for Entity Attributes Version 1.0 > SAML V2.0 Metadata Interoperability Profile Version 1.0 Minor errata were incurred as these documents transitioned from CD to CS. SC has no plans to bring these documents back to the Working Draft stage to correct these non-substantive errata. SC posted relevant attestations to the mailing list: http://lists.oasis-open.org/archives/security-services/200909/msg00035.html If there any other implementations of these (or any other CS) specs, please submit a formal attestation so these documents can move forward. > SAML V2.0 Holder-of-Key Web Browser SSO Profile Version 1.0 as a CS > SAML V2.0 Holder-of-Key Assertion Profile Version 1.0 Similar to the previous three documents, TS reports that these two documents also incurred errata as they were transitioned from CD to CS. This includes a normative reference from the Holder-of-Key Web Browser SSO Profile (CS) to the Holder-of-Key Assertion Profile (CD). The only way to correct this (and other) errata is to bring these documents back to Working Draft. NK agrees we should do this. Editors take note: In the future, OASIS tc-admin will transition documents from CD to CS. This means that all modifications to the CS version (apart from dates and version numbers) must be anticipated in advance. > (c) 15-Day review of sstc-saml-approved-errata-2.0-draft-49 (action for Hal) This document was previously ost, then found. An announcement is imminent. > (d) Progress on getting Jira instance for SSTC (Scott). No update. > (e) Dwayne to add a page for the XSPA page in the SAML wiki. > http://www.oasis-open.org/apps/org/workgroup/security/ballots.php DD reports this is done: http://wiki.oasis-open.org/security/XSPASAML2Profile > (f) Kerberos related items (Josh): > - Kerberos Attribute profile (draft-02): > http://www.oasis-open.org/apps/org/workgroup/security/download.php/34160/sstc-saml-attribute-kerberos-02.odt > > - Kerberos Subject Confirmation Method (draft-00): > http://www.oasis-open.org/apps/org/workgroup/security/download.php/34161/sstc-saml-kerberos-subject-confirmation-method%2000.odt SC wonders if this new Confirmation Method (CM) is potentially controversial. (The spec proposes a new CM rather than using the existing holder-of-key CM.) It is likely WSS implementations may break. Also we seem to be setting a precedent, which is not bad per se, but we need to consider this proposal carefully. For background information on issue, please consult the following threads of discussion: http://lists.oasis-open.org/archives/security-services/200906/msg00027.html http://lists.oasis-open.org/archives/security-services/200907/msg00017.html http://lists.oasis-open.org/archives/security-services/200908/msg00016.html Further comments to the list, please. > (g) Expressing Identity Assurance profile for SAML2.0 (LOA) (Bob Morgan) > http://www.oasis-open.org/committees/download.php/34277/sstc-saml-assurance-profile-draft-01.pdf BM uploaded a new version of this document (above). Some sections were moved, an example was added, and other tweaks were made. No normative changes were made, however. BM believes this document is ready for CD. So moved (by BM). PM seconded. No objections. Motion caries unanimously. > (h) Delegation Condition Extension Profile (Scott) SC uploaded a new version of this document: http://www.oasis-open.org/committees/download.php/34357/sstc-saml-delegation-cd-02.pdf SC created a new introduction and included some new diagrams that describe multiple actors. The goal was to motivate the use cases. SC would like to get this document back out to public review. No substantive changes were made, however. SC moves to take the document to CD. BM seconds. No objections. Motion carries. Next step is to request a CS ballot. Is the schema correct? Yes, all schema fragments are valid. Are normative refs synchronized? There are no xrefs, so this shouldn't be a problem. SC moves the SSTC request a CS ballot. BM seconds. No objections. Motion carries. PS. Don't forget to include the voting member list in the CD, otherwise there won't be an opportunity to do this as the document is automatically transitioned to CS. > 5. New work items: > > (i) SAML Attribute Management protocol proposal (Thinh Nguyenphu/NSN) > http://www.oasis-open.org/committees/download.php/34222/SAML%20Attribute%20Mgt%20Protocol.ppt Thinh Nguyenphu gave the above presentation. He reviewed the use cases (slide 2) and proposed a new SAML Attribute Management Protocol (slide 4). HL: In what sense is the account at the SP transient? Answer: Basically, we have a stateless SP so we would like to save attributes back to the IdP. HL: Do the two use cases look the same to the IdP? Answer: Yes SC: As a point of clarification, the SSTC won't modify the SAML Standards. HL: Some comments were posted online: http://lists.oasis-open.org/archives/security-services/200909/msg00016.html HL: Recommends CARML (Liberty) for these use cases. Perhaps CARML should be contributed to the SAML TC? BM: All of CARML or just the relevant portions? (This of course would be up to the SSTC.) SC: ID-WSF solves these use cases as well. SC: Are there IPR issues associated with these use cases? FH: Can you solve this problem without the complexity of full ID-WSF? General consensus of the SSTC is that update capability is useful, but this isn't necessarily the job of this TC. We should leverage other solutions (CARML, SPML, etc.) if indeed they are relevant. > (ii) SAML Name Identifier protocol proposal (Thinh Nguyenphu/NSN) > http://www.oasis-open.org/committees/download.php/34221/SAML%20Name%20Identifier%20Protocol.ppt Christian Günther from Munich, Germany gave the above presentation SC: Why not just use federated login and persistent identifiers? RP: We have customers who have requested bulk import of identifiers from IdP to SP (and in one case, from SP to IdP). SC: (re second bullet on slide 3) Not clear why you need anything more than Web Browser SSO. Why does the SP send an identifier in this case? At this point, we're taking it to the list for further discussion. > 6. Assorted threads on saml-dev/comment list > - Oasis Identity Management 2009 (29-30 Sept, NIST, Gaithersburg, MD) > http://events.oasis-open.org/home/forum/2009/registration This is actually an OASIS event and OASIS members are encouraged to attend. New business: Scott uploaded a new errata draft: http://www.oasis-open.org/committees/download.php/34096/sstc-saml-errata-2.0-draft-50.pdf Next call four weeks from today: Tuesday, October 20, 2009 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]