[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wss] Official minutes for Sept 4/5 F2F (with minor corrections)
OASIS Web Services Security (WSS) TC Meeting Official Minutes September 4th & 5th 2002 Held at the Sofitel Hotel, Redwood City, CA. Agenda (as posted prior to the meeting) ======================================= 1. Welcome and Introductions/roll call 2. Assign minute taker(s) 3. Review of OASIS TC process 4. Review of TC charter 5. Establish standing rules for this TC 6. Assign roles (webmaster, editor etc.) 7. Discussion of how this TC relates to other committees in the security area 8. Discuss assigning a liaison to other security related standards committees 9. Update for this team on the OASIS/W3C joint meeting in Boston. 10. Submission of input documents 11. Discuss phone call sponsor for next call and agree schedule for phone calls. 12. Discuss location of next F2F meeting and sponsor 13. Main part of meeting - group discussion 14. Any other business 15. Close Those Present ============= The following people attended the meeting. (This list is ordered by last name) Adams, Don TIBCO Ahmed,Zahid Commerce One Alexander,Jan Systinet Anderson,Steve OpenNetwork Balabine,Igor IONA Boubez,Toufic Level-7 Cahill,Conor AOL Carpenter,Greg Nokia Cohen,Eric PwC (Observer) Cotton,Paul Microsoft de Boer,Martijn SAP DeMartini,Thomas ContentGuard Ducharme,Jim Netegrity (Observer) Elley,Yassir Sun Microsystems Ellison,Gary Sun Microsystems (Observer) Epstein,Jeremy webMethods Evans,Colleen Sonic Software Fetterer,Andrew CrossLogix Flinn,Don Quadrasis Furniss,Peter Choreology Garg,Praerit Microsoft (Observer) Godik,Simon Overxeer Gravengaard,Eric Reactivity Greenblatt,Sam Computer Associates Hallam-Baker,Phillip Verisign Hanoian,Geff Overxeer Herring,Erick Digital Evolution Hodges,Jeff Sun Microsystems Hollowood,Larry Bank of America (Observer) Hughes,Merlin Baltimore Technologies Kaler,Chris Microsoft (co-Chair) Kojo,Takashi NEC (Observer) Kudo,Yutaka Hitachi Kurt,Chris Microsoft Knouse,Charles Oblix Lawrence,Kelvin IBM (co-Chair) Lo,Charles Vodafone (Observer) Lockhart,Hal Entegrity Martin,Monica Drake Certivo, Inc. Monzillo,Ronald Sun Microsystems Moritz,Ron Computer Associates (Observer) Morgan,Bob (individual) Moses,Tim Entrust Mulchandani,Nand Oblix Munter,Joel Intel Mysore,Shivaram Sun Microsystems (Observer) Nadalin,Anthony IBM Nagaratnam,Nataraj IBM Nash,Andrew RSA Security Nishimura,Toshihiro Fujitsu Nobles,Mark LMI Philpott,Rob RSA Security Pilz,Gilbert E2open Pope,William Choreology Prafullchandra,Hemma Verisign Raman,Rajesh BEA Systems Reed,Ed Novell Reid,Irving Baltimore Rostin,Peter RSA Security Samar,Vipin Oracle Sankar,Krishna Cisco Schwarz,Jerry Oracle Sengodan,Senthil Nokia Shewchuk,John Microsoft Sharp,Shawn Cyclone Commerce Siebenlist,Frank Argonne National Lab Sodhi,Gavenraj Business Layers Srinivasan,Andre E2open Sweet,Andrew Perficient Thurston,Gene AmberPoint Trythall,Steve Sonic Software Vaideeswaran,Ganesh Documentum Vepa,Sirish Sybase Wei,Sam Documentum Weltman,Rob Netscape/AOL Wenzel,Pete SeeBeyond Total Present 76 Voting members present 66 Apologies ========= Apologies were received from the following people prior to the meeting. Cox, William BEA Systems Hondo, Maryann IBM O’Neill, Mark Vordel Wylie, Kirk Talking Blocks Summary of TC roles =================== The following volunteers kindly offered their services during the meeting. Secretary - Steve Anderson Issues list coordinator/editor - John Shewchuk Editors - Anthony Nadalin - Chris Kaler - Ron Monzilo - Phillip Hallam-Baker Web Master - Gavenraj Sodhi Detailed Minutes ================ What follows are the detailed minutes for the meeting. We divided up the minute taking duties amongst four kind volunteers as follows: Day 1 (am) – Yassir Elley Day 1 (pm) – Chris Kurt Day 2 (am) – Bob Morgan Day 2 (pm) – Hemma Prafullchandra Day 1 (Morning) =============== Minutes submitted by Yassir Elley SUMMARIZED MINUTES (full minutes for day 1 morning below) The meeting was called to order at 10:10 am 1) Karl Best greeted members and discussed some OASIS process. Roll call taken. 2) WSS TC Charter reviewed and chairs asked if TC members wanted clarification of any point. Lots of clarification wanted about charter, roadmap, scope, and use cases. 3) Standing Rules - Should we allow non-TC OASIS members to subscribe to mailing list? Unanimous YES vote. No action item needed. - Should we create a developers list? Unanimous YES vote. - Should we say voting MUST be done by phone or F2F? Majority vote: voting SHOULD be done by phone or F2F. 4) Roles that need to be established described. - Editor(s) - Webmaster(s) - Liaision(s) to other groups - Liasion Committee (part of Security JC) - Secretary/Minute Taker 5) Relationships to other groups mentioned. 6) Summary of W3C/OASIS Security Forum given (Boston). - Focus - Urgency - Convergence SUMMARY OF ACTION ITEMS *** ACTION ITEM 1: Chairs should contact Roadmap authors and ask them if they want to submit roadmap as non-normative reference document. *** ACTION ITEM 2: Phil should present a proposal tomorrow that discusses charter, roadmap, scope, and use cases. *** ACTION ITEM 3:Chairs tasked with creating "wss-dev" maililng list for developers and to put annotation on each list to describe it and put it on web. *** ACTION ITEM 4: Chairs publish URL for presentations to "wss" list. DETAILED MINUTES 1) Greeting * Karl Best greeted the TC members and suggested that they familiarize themselves with the two normative OASIS documents (OASIS Technical Committee Policy and OASIS IPR Policy). He said that two important things that the TC should do at this meeting are: * To clarify the charter * For owners of contributed work to state their patent encumbrances, copyright terms, and licensing terms. * Roll Call was then taken. The welcome from Karl was done before roll call to accommodate his schedule. 2) Review WSS TC Charter * Jeff Hodges: Do we have to vote on charter? * Kelvin Lawrence: No, but we can clarify the charter. * Krishna Sankar: Is roadmap part of the submission? * Kelvin: No, roadmap is in public domain as an overall guide. * Krishna: I'm fine with the roadmap, but we should clarify that when we say "roadmap" we mean the roadmap as published in April, 2002. * Chris Kaler: We can submit roadmap if needed. * (Tibco): Roadmap clarifies position of this TC in larger world and who's going to have relationships with other committees. * Kelvin: Let's approach authors of roadmap and ask for submission of roadmap as a reference document. * Ron Monzillo: Bad idea. Scope would become unlimited then. * Kelvin: But we don't want to be responsible for entire roadmap. * Ron: It's not necessary to say that we are working in this context. * Rob Phillpot: To submit it as reference document has no effect on charter. * Ron: That's why it shouldn't be in charter * Greg Carpenter: We don't want to attack entire architecture. * Phil Hallam-Baker: XTASS is not going to be SAML or vice versa * Jeff: But XTASS wasn't mentioned in SSTC charter. * Tim Moses: Are IBM/MS actively working on other parts of Roadmap * Tony Nadalin: Yes, IBM and MS are working on it. * Zahid Ahmed: Should we modify roadmap to align with our charter? * Kelvin: Maybe we can subtly change wording. * Toufic: Remove reference to roadmap from charter, but introduce roadmap as input reference document. * Hemma Prafullchandra: Leave language that leaves it in but have authors submit it as input. * Phil: Observe that these objectives are part of wider roadmap and we do not want to solve the entire security problem * Ron: Will this group be defining roadmap? * John Shewchuk: To the extent that we remove roadmap to constrain work, we may have arbitrary feature creep. * Hal: The roadmap was developed by a much smaller group. People could disagree on charter. We shouldn't build it in our charter. * Greg: Rather than constraining scope, mentioning the roadmap in the charter actually potentially expands scope. * Tony: It constrains the scope. * Greg: If we need roadmap, we need it worked on formally. * Andrew Nash: Charter should not make reference to a roadmap on which there is no agreement. Should not be in charter. * Ed Reed: Since roadmap is not normative OASIS input or ouput, it shouldn't be normatively referenced. Use second page of charter as basis of deliverables. * Kelvin: We seem to have consensus that the roadmap should be submitted to TC as non-normative document. The disagreement is whether there should be a reference to the roadmap in the charter. * (unidentified speaker in back of room): We should start with the WS-Security input, polish it, and put it out as a standard. We can also add something to charter that we intend to produce use cases and someone can submit roadmap as input for use cases. * Phil: We are doing piece of security scope, not all of it. WS-Security was historically developed in context of roadmap and will be submitted as reference document. Need to rephrase the charter. *** ACTION ITEM 1: Chairs should contact Roadmap authors and ask them if they want to submit roadmap as non-normative reference document. *** ACTION ITEM 2: Phil should present a proposal tomorrow that discusses charter, roadmap, scope, and use cases. * Hal: OASIS rules allow TC to change charter at any time by majority vote. * (someone?): Can we have alternative mechanisms of signature and encryption other than XML DSIG and XML Encryption? * Chairs: Let's talk about this tomorrow. * Hal: There are two items we should discuss tomorrow: Alternative mechanisms of signature and encryption, and whether this group should produce use cases. 3) Standing Rules * Kelvin: Should we allow non-TC OASIS members to subscribe to email list? There was a unanimous YES vote. * ?: Should we create a developers list? There was a unanimous YES vote for creating developers list. *** ACTION ITEM 3:Chairs tasked with creating "wss-dev" maililng list for developers and to put annotation on each list to describe it and put it up on web. * Kelvin: Should TC voting be allowed by email? Chairs propose all voting MUST take place by phone or F2F. * Hal: OASIS says email vote must be announced in advance, while a phone vote must have majority of members present. Allowing email votes often has the result of delaying routine votes. * Jeremy Epstein: Voting by phone takes long time. * Greg: Taking roll call by phone can be inefficient. If email votes are inefficient, let's do it. * Steve Anderson: Let's not eliminate voting by email, but let's prefer phone votes and F2F votes. * Jeff: Supports Steve's comment - email votes require a lot. On phone, very seldom is roll call needed. If there is no objection, vote passes. If controversial, it requires work. We do roll call at beginning of meeting and asks for unanimous comment (if no objections). * Tibco: Secure email needed for secure voting. * Phil: Because we are a security TC, we really need to make sure that 90% of everyone agrees, rather than simple majority. Don't go for email. * Hal: Email votes, require 5 day period. Motion to prohibit email voting. Motion FAILED. Motion to change MUST to SHOULD. i.e. Voting SHOULD take place by phone or F2F. Motion PASSED. * ?: Are all our phone meetings automatically voting meetings? * Jeff: In SSTC, we published schedule of voting meetings and we only voted if quorum was established; else, we adjourn and do an ad-hoc (non-voting) subcommittee meeting. * Steve: Membership is also impacted by which meetings are voting meetings. * Phil: If you aren't planning on attending phone calls, please don't be a voting member. 4) Role Establishment * Kelvin: We need to establish several roles. If anyone is interested in any of these, approach chairs and let's get these established before we leave tomorrow. Roles include: - Editor(s) - Webmaster(s) - Liaision(s) to other groups - Liasion Committee (part of Security JC) - Secretary/Minute Taker 5) Relationship to other groups * Kelvin: Relationship to other groups, liasions. We should discuss how our work relates to other work in OASIS, W3C, IETF, etc, and discuss where we need to establish liaisions with other groups. 6) Summary of W3C/OASIS Security Forum * Chris: Also had someone from IETF there * Phil: Web Services are going to be big, not getting any anywhere without security, industry relying on us. Need to finish by six months. * Zahid: Any discussion on W3C Web Services Architecture WG Security Requirements at Forum? * Phil: No. * Yassir: Two main take-home messages: - Focus/Urgency (just say no to adding less important features) - Convergence (several dimensions) - vendor politics convergence - SAML/XACML vs. XRML convergence - B2B vs. EAI convergence - ebXML vs. WSDL/UDDI/SOAP convergence * Tony: Agreed with Yassir's take-home messages * Chris: Deep sense of urgency - Please don't take two years on this. All presentations have been published. *** ACTION ITEM 4: Chairs publish URL for presentations to wss list. The meeting was adjourned for lunch at 12:05pm. Day 1 (afternoon) ================= Minutes submitted by Chris Kurt Additional Introductions (1:05 - 1:10) New Attendees since initial introductions Paul Cotton - Microsoft Submission of Input Documents (1:10 - 1:10) (Chris Kaler) The set of input documents received on the lists were shown - WS-Security - WS-Security Addendum - WS-Security Profile of SAML (SSTC) - WS-Security XML Tokens This is a heads up; we will discuss the documents in detail a little later in the meeting. Next Meetings (1:10 - 1:30) (Kelvin Lawrence) The schedule for ongoing conference calls and minutes was discussed. RESOLVEFD, TC conference calls will be held every two weeks Passed unanimously ACTION ITEM: Chairs to propose times for conference calls. 6:00am Pacific was proposed as a time that may work for both European and Asia/Pacific members Using eVote.com services was proposed as a mechanism that may be useful for TC voting. It was also proposed that the times change every few months to accommodate the different contintents. Krishna Sankar (Cisco), Jeff Hodges (Sun), and Jeffrey Schwartz (Oracle) have offered to sponsor the next TC phone conferences. Volunteers to host the next F2F meeting: John Shewchuk (Microsoft) Hemma Prafullchandra (VeriSign) Tony Nadalin (IBM) ? (Computer Associates) Andrew Nash (RSA - East Coast) The timing for the next face to face meeting was discussed. RESOLVED, The next TC F2F meeting will be held in early November Passed unanimously Document Discussion (1:30 - 2:40) SUBMISSION: WS-Security Specification FROM: Co-Submitted by Hemma Prafullchandra (VeriSign) , John Shewchuk (Microsoft), Tony Nadalin (IBM) DISCLOSURE: IP on this specification may be held by VeriSign, Microsoft, and IBM. LICENSING: RF and other RAND terms John Shewchuk opened a discussion on the WS-Security specification. Q: What were the initial requirements driving the specificaitons? A: Security for SOAP messaging. Many of the use cases were documented in the roadmap. Additionally, the desire is simplicity Q: Does WS-Security prohibit use of other headers or other types of encryption? A: WS-Security adds a common schema to help SOAP processors handle secure messages. It does not necessarily prohibit other approaches. Q: Is there going to be a requirements section in the specification? A: It is up to the TC to decide. Typically, this informaiton is provided in a separate document. Q: Is there a need to usage scenarios? A: Deferred until a later conversation. This is something to consider later in the meeting. Q: Does WS-Security assume SOAP 1.1? A: Intended to work with 1.2 or 1.1. The document states 1.2 to support the new functionality. 1.1 is not precluded. A: The Addendum specifically says that it should support all versions. Q. Were SOAP-Sec and ebXML specifications reviewed? A: Maryann Hondo provided input on ebXML. MS and IBM reviewed the SOAP-Sec approach as input. XML Signature and XML Encryption were reviewed as well. SUBMISSION: WS-Security Addendum FROM: Co-Submitted by Hemma Prafullchandra (VeriSign) , John Shewchuk (Microsoft), Tony Nadalin (IBM) DISCLOSURE: IP on this specification may be held by VeriSign, Microsoft, and IBM. LICENSING: RF and other RAND terms - terms are identical to those in the WS-Security specification Tony Nadalin opened a discussion on the WS-Security Addendum specification. The Addendum is a set of clarifications coming out of implementation and interop testing of the WS-Security specifications. Q: What is the purpose of the AppNote that was published? A: The application note provides information for implementers to use for WS-Security and shows some sample messages. Q: Can the appnote be used for use cases? A: The use cases are the same as those published in the security roadmap. Q: Where was the appnote published? A: Microsoft and IBM sites have the appnote published. Q: Should an appnote be developed for the new WS-Security specification? A: This should be included in the later discussion on the roadmap. A: It was suggested that this type of informaiton be included in non-normative appendicies to the specifications PROPOSED SUBMISSION: WS-Security Profile of SAML (SSTC) FROM: Jeff Hodges (Sun) asserts that all members of the TC are submitting the specification DISCLOSURE: no terms specified. LICENSING: no terms specified. ACTION ITEM: Submitters must clarify the licensing terms and IPR around this submission RSA has not decided whether they will license their IPR to the WS-Security TC. Jeff Hoges opened a discussion on the WS-Security Profile of SAML document. Q: How do SAML assertions reference elements in WS-Security? A: They do not. The relationship runs from WS-Security to the tokens, not vice-versa. Q: Do SAML token and WS-Security token references need to be reconciled? Q: Is the SAML profile needed in the WS-Security specification? Q: Do we need to define the usage and content of a token in WS-Security? Q: How do we address additional types of tokens within the TC? Q: (more questions and discussion...) PROPOSED SUBMISSION: WS-Security XML Tokens FROM: Philip Hallam-Baker (VeriSign), John Shewchuk (Microsoft), Tony Nadalin (IBM) DISCLOSURE: Microsoft, IBM, and VeriSign may be held by VeriSign, Microsoft, and IBM LICENSING: RF and other RAND terms - terms are identical to those in the WS-Security specification Philip opened a discussion on this specification Comment: The approach should not reference the internals of a security token. Q: Is there significant conflict in the two token documents? A: There are technical issues to be resolved, but not irreconcilable differences. Q: Is there an action item to resolve the differences? A: We need to decide if this is work we want to do within the TC, assuming the submission of the document is worked out. Output Documents, Issues, and Approach (2:40 - ) (Kelvin Lawrence) Output Documents: RESOLUTION: The TC will create the following documents - Step 1: Merge WS-Security specification and Addendum document - Step 2: Establish a general framework for tokens and the general approch to tokens to the merged WS-Security spec - Step 3: Document Additional guidelines for each type of token - SAML - XrML Passed unanimously RESOLUTION: An additional document will be created for the X.509/Kerberos token Passed unanimously RESOLUTION: Solicit other committees/orgs to submit profiles for their work as additional profiles for WS-Security Passed unanimously Q: What parts of this approach are normative? Must someone who implements WS-Security support all types of tokens, etc.? Q: What sort of interop and conformance specifications should be written? Q: Where does username/password fit as a token? Break (3:00 - 3:45) Attendance Update (3:45 - 3:50) Peter (Choreology) Gavin (Business Layers) Steve (e2open) Selim (Intel) Dale (Sterling? Commerce) Liaisons (3:50 - 4:30) (Kelvin Lawrence) Proposed Liaisons: - W3C Web Services Architecture Representative: Hal Lockhart - Security Services TC Representatives: Jeff Hodges - Provisioning Services TC Representatives: Gavenraj Sodhi - OASIS Security JC Representative: Chris/Kelvin/Philip - W3C XKMS Representative: Yassir Elley - XACML Representative: Tim Moses - IEEE PKI Working Group Representative: defer - Rights Language TC (XrML) Representative: Thomas DeMartini - Open Grid Services Architecture Security WG (Global Grid Forum) Representative: Frank Siebenlist - UDDI Representative: defer - ebXML Representative: defer - Liberty Alliance Representative: Conor Cahil - IBM/Microsoft Roadmap Team Representative: Chris/Kelvin to investigate - W3C XML Protocol Representative: defer - Open Mobile Alliance Representative: Senthil Sengodan - IETF X.509 Representative: deferred - Biometric Markup Language TC Representative: via OASIS Security JC - WS-I Representative: Jerry Schwarz - WSIA/WSRP Representative: via OASIS Security JC - XML DSIG and Encryption Representative: Merlin Hughes ACTION ITEM: Chris/Kelvin to contact ebXML chairs ACTION ITEM: Chris/Kelvin to contact UDDI chairs Secretary: Steve Anderson Webmaster: Gavenraj Sodhi Editors: Philip Hallem-Baker, Tony Nadalin, Chris Kaler, Ron Monzilla Issue List: John Shewchuk Tomorrow's Agenda (4:30 -) (Kelvin Lawrence) Items for tomorrow - Revisit charter clarifications - Scope and deliverables - Roadmap document - Use cases - Security Quality - Deliverable schedule - XKMS Day 2 (morning) =============== Minutes provided by Bob Morgan 2002-09-05 acronyms->names PHB: Phill Hallam-Baker HL: Hal Lockhart JH: Jeff Hodges RM: Ron Monzillo PC: Paul Cotton TN: Tony Nadalin BM: Bob Morgan ZA: Zahid Ahmed DF: Don Flinn RP: Rob Philpott CK: Chris Kaler KL: Kelvin Lawrence CKurt: Chris Kurt charter clarification, PHB process says we can clarify charter but not "change its meaning", since people have come to TC based on existing charter proposed change: add one sentence to existing charter "The TC shall not further develop the security roadmap, nor shall the roadmap constitute a normative part of the WS-Security specification." moved and seconded to so modify charter HL/JH propose alternative that modifies two existing sentences. PHB rejects this modification. RM: modify end to "the output of the TC", result is "The TC shall not further develop the security roadmap, nor shall the roadmap constitute a normative part of the output of the TC." This change was voted on and unanimously approved. Discussion moves to proposed mods to first two sentences. Does the proposed change modify scope? discussion on this point. HL: move to make no further changes to charter statement. This fails, with split vote (approx 2/3-1/3). JH: move to accept modified paragraphs: "The purpose of the Web Services Security TC (WSS) is to continue work on the Web services security foundations as described in the WS-Security specification, which was written within the context of the Web Services Security Roadmap as published April 2002 . The work of the WSS TC will form the necessary technical foundation for higher-level security services which are to be defined in other specifications. The TC shall not further develop the security roadmap, nor shall the roadmap constitute a normative part of the output of the TC." Discussion of meaning of new and old sentences. This modification was voted on and accepted with a split vote (one opposed). discussion of other charter text, in set of bullets regarding "method of execution": JH: propose to clarify first bullet about accepting documents: Accept as input the Web Services Security (WS-Security) specification published by IBM, Microsoft, and VeriSign on April 11th 2002 , and other subssequent submitted (and approved) documents. This modification was voted on and approved unanimously. PC: propose modifying first sentence of second bullet: "Produce as output a specification, in one or more documents, ..." This modification was voted on and accepted, with a split vote. There was then discussion about wordsmithing, which was discouraged. HL: move to accept 1-5 bullets in execution part of charter. This was voted on and accepted, with a split vote. Discussion moved to a-f bullets in "specific technical items" section of charter RM: propose to replace final bullet on security tokens with: "Representing specific forms of security tokens." TN: proposed friendly to modify this to say "as specified in input documents." RM: reject this friendly discussion continued on this point: concern that group shouldn't be defining new tokens but also not have to list all tokens in charter BM: propose to add "an initial set of" RM: reject this friendly discussion: concern about whether extensibility, including registration and profile procedures, needs to be specified this was voted on and accepted unanimously: "Representing specific forms of security tokens." RM: question about "associating signatures" bullet does this mean specifying "proof of possession" rules? TN: it doesn't rule this out ??: regarding other possible forms of signature/encryption, this is needed ZA: for example, should be able to reference PKCS-7-protected element from header ??: how about using ASN.1 objects? TN: can include these as binary tokens, this has been demonstrated BM: what is process of the TC? is the list of things in this scope list prescriptive or descriptive? DF: propose new bullet: "develop a procedure for registering additional security tokens" various friendlies leading to text of: "ensure a mechanism for unambiguously identifying types of security tokens." RM: counter-proposal: don't add this bullet, also remove previous last bullet on "representing specific forms" Discussion on this: intention is to remove prescriptiveness, permit technical work as required to meet the remaining goals, eg identification/registration of new tokens. This modification was voted on and accepted on a split vote; now only the original a-e "scope" bullets remain. RP: again, does this list exclude other activities? HL: agreed, don't want to have to amend charter to do more work ??: perhaps we need an out-of-scope list CK: but an out-of-scope list could be very large ??: move that set of scope bullets be accepted as the set of things that the committee *must* produce CK: this is implicit in it being in the charter, proposal is moot ??: is there an item on the floor about alternative sig/enc methods? CK: there was no motion about this. Move to discussion of Deliverables CKurt: propose that we take the agreement from yesterday on documents as initial set of normative deliverables, that is: * "the core specification": (merged WS-Sec/Addendum, with framework from XML tokens doc) * SAML profile * XrML profile * Kerberos profile * X.509 profile is XrML a submitted specification? yes, submitted to MPEG committee does OASIS process permit revising deliverables list as we go? CKurt: yes ??: propose friendly to remove XrML and Kerberos CKurt: rejected This statement was voted on and passed unanimously. ??: move to modify deliverables to remove XrML based on problems with XrML spec, low priority JS: it is used today CK: we've had several votes to accept it so far JS: having two XML sec tokens makes sure we can do others HL: XrML 2.1 has been submitted to OASIS RLTC, as an input ??: OK, motion withdrawn. CK: proposals for name of core spec? HL: propose "Web Services Security Core Specification" TN: propose "Web Services Message Security" PHB: call the set "WSS", the core doc "Message Security" JS: propose subcommittee to recommend doc names HL and RP and PC volunteer potential non-normative documents use cases primer WS-Security app note requirements security considerations interaction with XKMS conformance profiles privacy considerations security token registration best practices testable conformance deployment template rationale - history issues list what is "security considerations"? section in IETF docs, also SAML/XACML notes to implementors on how to build/deploy securely what is "conformance profile"? statements about required feature sets for different uses Day 2 (afternoon) ================= Minutes submitted by Hemma Prafullchandra Potential Non-normative deliverables: 1. Use cases Propose a small sub-committee to pull it together. Ckurt: Purposes for this are 1)drive reqs, and 2) way to amplify how this would be used in practice. So what is the purpose here? Zahid: need to identify class of applications, e.g. peer-to-peer, business apps, need to come out with a set of concrete uses cases. Rob(RSA): by analyzing the use cases we will come out with some specific requirements that may need to be addressed., and also to help settle some of the issues that may come up during the discussions. RonZ: there is supporting information in the AppNote of use cases that should/would be addressed. PHB: proposes writing a book! Would like an instance worked out – e.g. a payment protocol, but would expect other committees to do so, unless that committee is near closure. Concrete instance docs are important. Paul: Doing Use cases will help us understand and clarify this work. Would suggest that the Use cases should be made normative but that does not make sense. What is the relationship between the core doc and the use case doc? PHB: we are providing a particular set of web services security, we are not going to be comprehensive on requirements. Yassir: our statement of work can be made into a requirements doc. We need to agree on what we want to use, the use cases will represent the requirements from each vendor represented in the TC. JeremyEpstein: Use cases are useful to explain to external parties. GregC: would like a reqs doc for reasons already stated. If more than one vendor identifies use cases than they would take higher precedence, and should be considered as TC output (non-normative). Editors act as collectors of the use cases and should use them where they see fit. Zahid: not all use cases should be accepted, they should be vetted for applicability and then only used. Rob(RSA): some coordination will be required for managing the use cases. PHB: as editor does not want to write about use cases. It would be genuinely useful to have a document archive that can be reviewed by fellow members and if there is sufficient interest then those folks can bring it to the TC. Yassir: if someone feels really strongly then they can sign up Zahid: would like the use case submissions to be collected Ckurt: if this is only a submission process for Use cases then what is the usefulness? We should have the TC accept use cases and they should be supported within ws-sec Paul: necessary step but insufficient to gain interoperability. Both demonstrate how to use the specs and to test their work with. Zahid: have a vetted, consolidated set of use cases. TimMoses: one camp would like to do this in a waterfall fashion. Only look for use cases that are not currently addressed in the input docs. GregC: unless the use cases are going to produce specific reqs this would be a wasted effort. Ckurt: 3-4 of the items listed should/can be rolled into a single doc. Should we go thru’ the list before we decide what to do on each one. CK: ACTION: need to determine interest in a Use case doc – 10 members showed interest. 2. Primer PHB: does not think there is sufficient meat in this work area to write a primer. 3. WS-Security AppNotes 4. Requirements 5. Security Considerations 6. Application of ws-security to XKMS, Interaction w/ XKMS 7. Conformance Profiles - defer 8. Privacy concerns 9. Security token registration 10. Best practices 11. Interoperability 12. Testable conformance - defer 13. Deployment templates 14. Rationale 15. Issues List (mandatory) Ronz: bucket #1, #2, #3, #14 - two objections, motion not carried. What is the difference between #1 and #3? Joel used #3 to come up to speed – how do I use it (applies to appnotes & best practices). Primer says what it is. Combine #1 and #2 – motion carried. Jerry/Oracle – withdraw Rationale (#14). Requirements – move to normative list. Combine #7 & #12? What are the compliance requirements? Need to be able to support variance in what needs to be supported. We should defer this until we know that we need. Should the core doc deal with conformance? CK: there will be instances when the core may not cover all aspects. Deferred. Merge #5 and #8 and make it part of the core and the profile docs and make it non-normative. Doc #9 Yassir – want some mechanism to officially give the token a name. CK: we discussed this in the morning, and decided it was redundant Conor: we have to wait until the solution is defined. Defer until we have some drafts to look at. Doc #3 Would like to see AppNote submitted as input doc. CK/KL: ACTION – approach the author to submit the AppNote to this TC. Joel: will this TC publish a best practices and an appnote, this is a longer term work item. PHB: ietf has best current practices document, it is typically an input to the stds process; not as an output. TC AppNote – deferred. Doc #11 – Paul not present – defer for now. Doc #13 Deployment template provide details of usage for specific verticals, it allows a community to decide what should be needed. This is to provide a template. Joel: What is the relationship with WS-I and WSS TC on conformance/interoperability ? CK: there are many bodies that to do something similar Jerry: as liaison to WS-I he will coordinate this effort. Hal: seems like we should identify things that are important to the success of this TC and then allow other bodies to do the work. PHB – want to finish XKMS, the binding to ws-sec needs to be addressed. However, if that W3C wg is still working then we can do the work there otherwise he would like to have that work done within this TC. RonZ: why is XKMS not just a use case? PHB: It is RZ: Then why is it being called out? PHB: Because the output needs to be normative. He will submit XKMS II as input to this TC. It would allow the XKMS wg to dispand. It would be a normative document to XKMS if it uses ws-sec, not mandatory. CK: can we defer this until one of the trigger conditions is met? PHB: yes, he can now discuss that this was raised in this TC tomorrow at the xkms wg mtg. Eric Karin(sp?) – volunteers to chair the subcommittee to work on the primer and use cases. This committee should decide on whether these two are combined or should be treated as separate docs. The subcommittee needs to figure out the rules of engagement under OASIS – they are not required to establish formal charter, etc. Requirements doc (#4): KL: do we do this as we find requirements? Hal: earlier there was a discussion to have this be part of the normative core doc. CK: should we fold scoping points into the core docs as normative. CK: due to lack of interest – we will drop this and revisit later if need be Yassir: in xkms they have a requirements doc, it defines what is in scope. KL: charter already defines the scope Yassir: it allows for detailed specifics. Timeline/Schedule 1st telecon in two weeks. 2nd f2f in early nov. Editors – should use the mailing list for discussions immediately Folks should use the list to suggest agenda items for the next telecon. Hemma: it only makes sense to schedule the next mtg after we have the first drafts posted. Then all discussions will be based on the posted drafts. Goal prior to the next mtg is for: * The Editors to scope the work and produce the first drafts, and * The Sub-Committees to form and start initial discussions. We want to be faster rather than slower – what would we mark as a success, provide a general timeline. Yassir we should be very aggressive with core doc and aggressive for the other docs. Publish docs prior to calls. CK: we should have solid drafts of the profiles, so that we know we’ve captured all the corner cases. There is an OASIS board mtg in September and there is a proposal to change from a quarterly window to a monthly window, and would become effective immediately. CKurt: believes that it would likely be approved. JeffH: and assuming the OASIS team has the bandwidth to deal with this new timeline. JeffH: in sstc they declared a date and found it was useful and motivational for the members. They did slip, and this helped them focus down. JeffH: Say March/April for submission to OASIS Hal: freeze a month so that implementation can be made CK: ACTION: let us pick a date for the OASIS submission after the first drafts are available Rob/Ron: to be able to submit to OASIS we need three implementations – this is not a formal requirement, but makes sense. CKurt: process says “successfully using it” PHB: if members are going to suggest whacky changes then developers are going to have a hard time implementing within the given timeline. CK: ACTION: we should discuss if we want an interop fest at some later time. Any other business Hal: has a technical proposal that he will submit to the list TimMoses: quality of security/protection, we’ve declared the activity as web service security – it is broader than securing soap messages. One issue we are going to run into is which algorithms are supported by peer entities, which elements are secured, etc. This could be step two in our timeline. It would be appropriate to at least explore the issue, existing work, etc. This should in no way hold up the primary work item. If there is interest then a subcommittee should be formed to tackle this, and report back. This is an item on the roadmap so should we wait or do this in this TC? TN: is this in scope of this TC? Tim: this is a suggestion, that this be a next item in the work queue. JS: we should just start a new committee to address this? PHB: we need to do some marketecture – we should successfully complete ws-sec and then start shooting for other spec. Establishing new OASIS TC is easy, very little overhead, as compared to W3C. ?: Support the previous two speakers to do it in another committee. Rob/RSA: does this TC dispand after 6 mths and has finished it s work, or do we do preliminary work for the next work item. PHB: standing working grps are not good – created an enormous barrier to creating new grps, and keeping alive existing wg. RonZ: agrees that we shd keep the charter small, but recognizes items like proof-of-possession and correlation are needed and make sense to address. There is more for us to do. Joel: will the lack of these discussions hurt adoption of ws-sec? We do not have enough information. Hemma: we should not introduce new work items into the TC as non-members are not aware of these. If we do, then we should make that public. Yassir: is it feasible that the QofSecurity items be established out of band. Hal: what is the interval? Tim’s proposal will be highly dependent on this TC’s work. Yassir: In XML Dsig these are established out-of-band. Crypto negotiation and such are done in-line in SSL/TLS and S/MIME. ?: WSDL definition of how security is represented, and may be handled that way. Zahid: would like to see a technical presentation on what this is? EbXML also has some work in this area. ?: We have disagreement on what this TC shd be working on? Is it web services security or soap security. Depending on which one it is, then Tim’s proposal either belongs or does not. The name implies the former. CK: initial charter/scope did not call out QofSecurity and we so we may not have all the members that may want to participate in this activity. ? : We can collaborate with WSDL to work on QofSecurity. Paul: Do we have the resources to form a subcommittee to look at this? Don/Quadrasis: if we are going to finish this in a very short time., then we need do this in baby steps and focus on each step at a time. Rob/RSA: There is concern that we do not want to work on the big picture and so forming subcommittees may allow us to address “web services security”. Yassir: if folks have cycles then they should work on it JohnS: we should announce that we want to work on this area, and then the new folks can work on this item. Tim: OASIS does have a discussion group concept, declared topic, requires three members to participate to start the work. Rob/RSA: believes that it most likely will come back to this TC. Jerry: will these consideration result in technical feedback, e.g. error codes. So feedback from the Discussion group is welcomed. Tim volunteers to set up a discussion group – Tony Nadalin, RonZ inidicated interest. Others should make their interest known to Tim Moses of entrust. Hal: present minor technical change/additioin to ws-sec core spec. Basic idea we have allows various kinds of authorizations token that represent various identities. Optionally label these tokens to define the relationship between participants in a business transaction. E.g. a patient makes a request to send their records to a doctor. The requestor and the real recipient are two different individuals. E.g. passive delegation, distinguish between the original and intermediary E.g. active delegation, establish a relationship with a code base Need to define these other types of subjects and their relationship to the actors. Will write this up and circulate on the list. Is this like a “role”? No not in the soap sense but more about “who” the token relates to in terms of the business transaction. Any other business WSDL does have a service definition – should this be in scope? Need to make a formal presentation to its applicability. JeffH: the present input spec has a dependency on ws-routing – so what is the deal? JohnS: you may route these messages thru’ intermediaries and the spec describes how it should and should not be processed. ACTION: editor must remove all references to ws-routing and such. Thanks our host – sun Microsystems. Thanks to our co-chairs.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC