[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Re: Proposed Agenda for SSTC Call (May 18,2010)
On 05/18/2010 12:23 PM, Anil Saldhana wrote: > 1) Roll Call > > Voting Members: > Nathan Klingenstein Internet2 > Thomas Hardjono M.I.T. > Frederick Hirsch Nokia Corporation > Thinh Nguyenphu Nokia Siemens Networks GmbH & Co. KG > Hal Lockhart Oracle Corporation > Emily Xu Oracle Corporation > Anil Saldhana Red Hat > David Staggs Veterans Health Administration > > Members: > Phil Hunt Oracle Corporation > Ari Kermaier Oracle Corporation Frederico Rossini Telecom Italia > > Quorum: 8 out of 14 voting members (57%) > Status: Phil Hunt and Ari Kermaier get voting rights. Tony Nadalin > loses voting rights. > > On 05/18/2010 12:07 PM, Nate Klingenstein wrote: >>> 3. Approval of minutes from last meetings: >>> Minutes from SSTC Call on 4 May 2010: >>> http://www.oasis-open.org/apps/org/workgroup/security/email/archives/201005/msg00011.html >>> >> Hal moves to approve the minutes from the prior call, and Anil >> seconded it. There were no objections, and the minutes were approved. >> >>> (c) SAML V2.0 Holder-of-Key Web Browser SSO Profile Version 1.0 as >>> a CS >>> - Status: Thomas has formally asked Mary for new Ballot. >>> (3/11th) >>> - Status: Mary has acknowledged, and is setting up ballot >>> currently. (4/15) >>> - Status: Thomas has followed-up again with Mary to request >>> Ballot (May/14th). >> Thomas has not heard back on his newest follow-up with Mary. >> >>> (d) SAML V2.0 Holder-of-Key Assertion Profile Version 1.0 >>> - Status: CS-01 version of this doc is on WiKi. >> [AI] Thomas will make sure this goes into the OASIS Doctree as well. >> >>> (e) Kerberos related items. [Josh/Thomas] >>> - Kerberos Web Browser SSO Profile: >>> - Status: In 60-day review. >>> >>> (f) Expressing Identity Assurance profile for SAML2.0 (LOA) >>> - Status: In 60-day review. >> Please review these profiles and comment if necessary. >> >>> (g) Older docs: Thomas has formally asked Mary to post these 4 >>> docs (3/11th) >>> (I) Protocol Extension for Third-Party Requests (CS-01) >>> (II) Protocol Extension for Requested Authentication Context >>> (CS-01) >>> (III) Shared Credentials Authentication Context Extension and >>> Related Classes (CS-01) >>> (IV) Text-based Challenge/Response (CS-01) >>> AI: Thomas to request Mary again (Thomas AI from May/4th SSTC >>> Call) >> Still waiting. >> >>> (i) NSN Attribute Update proposal (Thinh) - updates >>> >>> http://www.oasis-open.org/committees/download.php/37601/saml-2.0-mgmt-draft-02.zip >>> >> Phil and Thinh brought their ideas back to the group without full >> formalization because they wanted to capture the excellent ideas that >> had been presented last call. >> >> When a SP wants to provision a user in the modified model, the SP >> becomes its own quasi-IdP. The SP sends an unsolicited >> SAML<Response> with intent to provision to the target IdP. >> >> He was then concerned about, in step 6, how the SP indicates this >> action. In a normal SSO sense, you would use a RelayState to >> indicate where the user was bound for. We want to do provisioning >> instead, though, and it's not clear where that provisioning would be >> performed by the IdP. Scott prefers use of an extension to the >> response as part of profiling the communication rather than using >> RelayState. >> >> The IdP would then process the claims received in step 6 and either >> provision a new user account, or associate the Response with another >> account that already exists and is separately authenticated. The >> means by which the IdP does this is likely to be out of scope for the >> profile. >> >> Following that, there's a Response sent from the target IdP to the >> originating SP. The SP, expecting this response, could either accept >> this as success of provisioning, or changing the identity information >> or identifier located at the SP. >> >> Thinh is most interested in the use case where the SP is facilitating >> the user swapping primary IdP's by reprovisioning itself into a new >> IdP. But Nate doesn't want to see the set of use cases constrained >> too much, because he sees this general set of flows as very useful >> for a variety of scenarios. One is Thinh's, but he also thinks that >> attribute aggregation and initial provisioning of an identity would >> be other use cases. >> >> Deleting an account after this front-channel provisioning could be >> accomplished using the back-channel provisioning flows that NSN and >> Oracle had initially submitted to the group. Thinh now believes the >> AddSubject operation in that document should be shelved for the time >> being, focusing on the present front-channel approach to subject >> creation. The back-channel work in that document is still important >> and represents a separate but closely related profile. >> >> Nate and Thinh agree that the designation of SP's and IdP's in the >> proposal is a little arbitrary. Both providers are required at >> different points in the flow to act as either an IdP or an SP. The >> proposal could probably be generalized in order to allow for >> initiation of the flows at an IdP as well. Nate preferred that both >> entities simply be called "providers". Phil will think about this >> and consider another approach to diagramming it. >> >> Ari asked the group to consider using an AuthnRequest to convey the >> account creation request instead of a Response to kick off the >> process, with an extension to convey attributes, as he thought there >> would be less profiling and implementation work required to do so. >> Nate disagreed, because he believed the set of information that would >> be desirable includes everything that is in an assertion anyway; >> assertions are designed, after all, to carry and convey information >> about a principal from one provider to another. >> >> There was also discuss about whether the secondary Response back to >> the SP was a requirement. Nate thought it was an elegant way to >> either report successful provisioning or allow the SP to modify its >> own representation of the user, all using an existing protocol. >> Using an embedded AuthnRequest that Scott proposed on the email list >> could be a nice way to associate the IdP's new Response with the >> initial provisioning Response. Upon receiving the Response, the SP >> could initiate other actions as required to fulfill its use case. It >> may be that the second Response is indeed optional, but Nate felt >> this would only become apparent after more concretely profiling the >> flows and applying them to some use cases. >> >>> (j) Metadata Interop profile (Scott) - updates >>> Status: Scott waiting for comments from ICAM folks. >> Scott was absent today, but Thomas believes that Scott is still waiting. >> >>> 6. Assorted threads on saml-dev/comment list: >>> - SP initiated authentication and provisioning. >>> - Call for Presentations for OASIS Identity Management 2010 >>> Conference >> There is a chance to hold a face-to-face meeting of the OASIS-SSTC at >> this conference, on the 27th and 28th of September. Thomas asked >> folks to note this in their calendars. >> >> Hal has concerns about the cost and cut-off time. A decision should >> be reached before that. > > ---------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]