[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for July 13 SSTC Call
AGENDA: 1. Roll Call & Agenda Review. 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]