[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[1], which was written within the context of
the Web Services Security Roadmap as published April 2002 [2]. 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 [1], 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