[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Minutes for July 13 SSTC Call
On 07/27/2010 09:48 AM, Anil Saldhana wrote: > On 07/13/2010 12:31 PM, Paul Madsen wrote: >> AGENDA: >> >> 1. Roll Call & Agenda Review. >> > Voting Members: > John Bradley Individual > Nathan Klingenstein Internet2 > Thomas Hardjono M.I.T. > Anthony Nadalin Microsoft Corporation > Thinh Nguyenphu Nokia Siemens Networks GmbH & Co. KG > Hal Lockhart Oracle Corporation > Emily Xu Oracle Corporation > Anil Saldhana Red Hat > Rob Philpott, EMC Corporation > Members: > Paul Madsen NTT Corporation > Federico Rossini Telecom Italia S.p.a. > > Status: Ari Kermaier lost voting rights. > Quorum: 9 out of 14 (64%) >> Quorum met >> >> 2. Need a volunteer to take minutes. >> >> Paul will minute >> >> 3. Approval of minutes from last meetings: >> >> Minutes from SSTC Call on 29 June 2010: >> http://www.oasis-open.org/apps/org/workgroup/security/email/archives/201007/msg00000.html >> >> >> John B moves to approve, Hal seconds. >> >> No objections, minutes approved >> >> 4. AIs & progress update on current work-items: >> >> (a) Current electronic ballots: None >> >> (b) Status/notes regarding past ballots: None. >> >> (c) SAML V2.0 Holder-of-Key Web Browser SSO Profile Version 1.0 as a CS >> - Status: New ballot has been requested. Still awaiting. >> http://www.oasis-open.org/apps/org/workgroup/security/email/archives/201006/msg00032.html >> >> >> Did not have sufficient votes 3 weeks ago. Pending with Mary >> >> Hal notes that OASIS had email problems a week ago. Some messages may >> have been lost. >> >> Thomas will follow up with Mary to confirm >> >> (d) SAML V2.0 Holder-of-Key Assertion Profile Version 1.0 >> - Status: CS-01 version of this doc is on WiKi. >> - AI: Thomas to ask Mary to move into Doc tree. >> - Status: Awaiting Mary. >> >> Thomas needs to follow up with Mary to move document >> >> (e) Kerberos related items. [Josh/Thomas] >> - Kerberos Web Browser SSO Profile: >> - Status: Public review period closed on 15 June 2010. >> - Status: Comments received for Attribute profile. Spec will be updated. >> >> Thomas and Josh received comments from Carnegie Mellon - an >> interesting use case. Will update attribute profile spec >> >> Dialog is on comments list for SSTC >> >> (f) Expressing Identity Assurance profile for SAML2.0 (LOA) >> - Status: Public review period closed on 13 June 2010. >> - Status: Awaiting comments/resolutions. >> >> Paul, Scott and I reworking, will be uploaded in near term >> >> Hal, OASIS process requires that , perhaps at CS status, that all >> comments are acknowledged and addressed. As a courtesy, we could >> respond through email to commenters >> >> (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) >> - Status: Posted. >> >> http://docs.oasis-open.org/security/saml/SpecDrafts-Post2.0/sstc-saml-protocol-ext-thirdparty.html >> >> http://docs.oasis-open.org/security/saml/SpecDrafts-Post2.0/sstc-saml-protocol-ext-rac-cs-01.html >> >> http://docs.oasis-open.org/security/saml/SpecDrafts-Post2.0/sstc-saml-context-ext-sc-cs-01.html >> >> http://http://docs.oasis-open.org/security/saml/SpecDrafts-Post2.0/sstc-saml-text-based-challenge-response-authn-context-class-cs-01.html >> >> >> >> (h) SOA-TEL Token Correlation Profile (Federico/TI) >> http://www.oasis-open.org/committees/download.php/38374/sstc-saml-token%20correlation-profile-v0.8.pdf >> >> >> Federico & colleague will explain. >> >> Document defines the syntax to express a relation between two SAML >> assertion, a “main” >> one and a “related” one. >> >> The syntax defined defines a new security profile, in which a SAML >> assertion is >> syntactically and semantically meaningful if it is presented in >> relation with another “related” >> SAML assertion; it enables to express a relation between two security >> SAML assertions >> >> 1. the SAML assertion cannot be built and considered valid if it >> isn't presented together with >> another “related” SAML assertion, >> >> 2. The authorization is granted only in presence of both the subjects >> of the two SAML assertions. >> >> Motivated by complex business processes >> >> Thomas asks 'would it be simpler if the first assertion were hashed, >> and the hash inserted into the second, both sent to SP? >> >> Federico - yes but we want to be able to express constraints on the 2 >> subjects of the 2 assertions. >> >> Thomas, is it not already possible to embed one assertion in another? >> >> Hal, you could put one assertion into the Advice of another. But not >> clear what semantic Federico is hoping to express with the embed? >> >> Thomas, believe they want an intermediary to hold onto SAML1 for a >> long running process, and when appropriate, be able to get a SAML2 >> assertion (with SAML1 within) >> >> Hal asks, why must they be embedded, why not simply have both >> assertions? >> >> Federico, simply require a strong link between the two assertions >> >> Thomas, existing <Advice> element allows embedding assertions? >> >> Federico, more important than the syntax, >> >> Nate, for SAML 1.1, is there not an issue with being able to sign an >> assertion? whcih would complicate this? >> >> Hal, thinks SAML 1.1 does allow >> >> Thomas, actually they are using SAML 2.0, just lisleading the labels >> on the diagram >> >> Nate, if the goal is to strongly link two assertions, you can embed, >> or point from one to the other >> >> Hal, is the linking fundamental? >> >> Nate, believe you cannot use the 2nd assertion without the first >> >> Paul, but <Advice> doesnt provide that semantic, better would be >> <Condition>? >> >> Nate, most important is how to represent the relationship from one >> assertion to another. >> Another issue to consider is how to avoid pointing to expired >> assertions, need to ensure that the lifetime of the first assertion >> exceeds the business process duration >> >> Federico, yes noted >> >> Paul, is the different audiences of the two assertion another issue? >> >> Nate, the delegation profile of Scott's could help here. >> >> Hal, dangerous to allow for ignoring an expiration time >> >> Nate, uncomfortable with an SP ignoring the mandatory assertion checks >> >> Hal, sounds more like a WS-Security use case....Dependency is in the >> context of this particular transaction, where signatures over >> messages could better express the semantic of the dependency >> >> Nate, we want to keep the assertion as representing identity >> >> Thomas, summary is that the assertions talk about the subjects >> (requestor and intermediary). The assertions dont carry enough info >> about the context of the transaction. perhaps easier to epxress the >> dependencies in WS-Sec. >> >> Federico, but what is the <Conditions> for if not this sort of thing? >> >> Nate agrees, thinks the assertions are being used for a >> capability/privilege model, >> >> Rob, Conditions can be anything, you define a new element of the >> ConditionType and extend appropriately >> >> Nate, Consensus is that <Conditions> is the appropriate soln for >> expressing the Token-Correlation, >> Could be either a pointer, or embedded. Both assertions should be >> valid when received by the SP >> >> Thin, Believe the proposal is to deal with expired assertions? SP >> requests an extension? >> >> Nate, dont think so, believe expiration is a separate problem. Core >> aspect for this use case is 'Validity of Token 1 depends on Token 2'. >> >> Thomas, can Federico come back and give an update? >> >> Feerico, yes, let me know when >> >> (h) NSN Attribute Management proposal (Thinh/Phil) - any updates? >> >> Phil indicated there would be an update posted soon >> >> (i) SSO initiation CD (Scott) - any updates? >> >> 5. New work items: >> - Project Moonshot (potential new work item) >> - IETF Federated Authentication BOF (at July IETF meeting) >> >> Hopefully Josh Howlett can brief us someday >> >> 6. Propose an SSTC Face-to-Face meeting for September 2010: >> - Awaiting for room confirmation. >> >> Still waiting to determine if we can get a room >> >> 8. Next Call: Tuesday 27 July, 2010. >> >> Nate moves to adjourn, Hal seconds >> >> Adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]