[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/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 Members: Paul Madsen NTT Corporation Federico Rossini Telecom Italia S.p.a. Status: Ari Kermaier lost voting rights. Quorum: 8 out of 14 (57%) > 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]