OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [security-services] pointer to WSSTC F2F Sep 4/5 2002 Minutes (draft)

[wss] WSS TC 

OASIS Web Services Security (WSS) TC Meeting
Official Minutes (draft)

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
8.      Discuss assigning a liaison to other security related standards
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
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          (individual)
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 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.

  - Steve Anderson

Issues list coordinator/editor
  - John Shewchuk

- 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

*** 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.

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
        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

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

        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
        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

        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

        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
        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
        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
        Q: How do we address additional types of tokens within the TC?
        Q: (more questions and discussion...)

        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

        Q: Is there significant conflict in the two token documents?
        A: There are technical issues to be resolved, but not irreconcilable

        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


  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
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)
This modification was voted on and approved unanimously.
PC:  propose modifying first sentence of second
  "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
  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
  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
  WS-Security app note
  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
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
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
We should have the TC accept use cases and they should be supported within
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

2. Primer
PHB: does not think there is sufficient meat in this work area to write a

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
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.

Merge #5 and #8 and make it part of the core and the profile docs and make it

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
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.


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
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
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
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
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