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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

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


Subject: OASIS WS-Security TC Minutes, Jan 13, 2004


OASIS WS-Security TC Minutes, Jan 13, 2004

> 1. Call to order, roll call

The meeting was called to order at 10:05am EST.  Kelvin Lawrence and 
Chris Kaler were in the Chair.  Paul Cotton acted as recording 
secretary for this meeting.

Attendance of Voting Members  

  Gene Thurston AmberPoint
  Frank Siebenlist Argonne National Lab
  Merlin Hughes Betrusted
  Peter Dapkus BEA
  Hal Lockhart BEA
  Symon Chang CommerceOne
  Thomas DeMartini ContentGuard
  Guillermo Lao ContentGuard
  TJ Pannu ContentGuard
  Sam Wei Documentum
  John Hughes Entegrity
  Toshihiro Nishimura Fujitsu
  Kefeng Chen GeoTrust
  Irving Reid HP
  Yutaka Kudo Hitachi
  Paula Austel IBM
  Derek Fu IBM
  Kelvin Lawrence IBM
  Anthony Nadalin IBM
  Nataraj Nagaratnam IBM
  Ron Williams IBM
  Don Flinn Individual
  Bob Morgan Individual
  Paul Cotton Microsoft
  Vijay Gajjala Microsoft
  Chris Kaler Microsoft
  Richard Levinson Netegrity
  Prateek Mishra Netegrity
  Frederick Hirsch Nokia
  Ed Reed Novell
  Charles Knouse Oblix
  Steve Anderson OpenNetwork
  Vipin Samar Oracle
  Jerry Schwarz Oracle
  Eric Gravengaard Reactivity
  Andrew Nash RSA Security
  Rob Philpott RSA Security
  Martijn de Boer SAP
  Blake Dournaee Sarvega
  Coumara Radja Sarvega
  Pete Wenzel SeeBeyond
  Jonathan Tourzan Sony
  Yassir Elley Sun Microsystems
  Jeff Hodges Sun Microsystems
  Ronald Monzillo Sun Microsystems
  Jan Alexander Systinet
  Don Adams TIBCO
  John Weiland US Navy
  Phillip Hallam-Baker VeriSign

Attendance of Prospective Members and Observers

  Maryann Hondo IBM
  Ben Hammond RSA Security
  Senthil Sengodan Nokia
  Ramana Turlapati Oracle
  Mike McIntosh IBM
  Shawn Gunsolley Booz Allen Hamilton
  Mike Colon Booze Allen Hamilton

Membership Status Changes

  Maryann Hondo IBM - Granted voting status after 1/13/2004 call
  Ben Hammond RSA Security - Granted voting status after 1/13/2004 call
  Kevin Lewis Documentum - Granted voting status after 1/13/2004 call
  Tim Alsop CyberSafe - Requested membership 12/16/2003
  cyc cyc IBM - Requested membership 12/18/2003
  Eleanor Robinson Individual - Requested membership 12/20/2003
  Mike McIntosh IBM - Requested membership 1/12/2004
  Shawn Gunsolley Booz Allen Hamilton - Requested membership 1/12/2004
  David  Orchard BEA Systems - Lost prospective status after 1/13/2004
call
  Jagdip Talla Crimson Logic - Lost prospective status after 1/13/2004
call
  Vijay Gajjala Microsoft - Returned from LOA 1/13/2004
  Alan Geller Microsoft - Requested membership 1/13/2004

The meeting had 48 voting members present out of 54 which represents a 
quorum.  
 
> 2. Reading/approving minutes of last meeting (Dec 16th) [1]

The minutes of the last meeting were adopted unanimously.
 
> 3. Status of documents (Editors/all)

Kelvin asked the Editors to review the status of the documents.

Tony Nadalin outlined the status of the WS-Security Core and the User 
Name Token Profile.  He thinks the most recent posting covers all the 
editorial comments up to late on Mon Jan 12 including the comment on 
HMAC.  Tony also made editorial corrections to the X509 Token Profile 
in Phil's absence.

The editors have not yet made the #### change in the URI's of the 

Namespaces and the document URLs since this information is not yet 
available from OASIS management.  The Chairs will ensure this is taken 
care of if the documents progress today.

Jerry Schwarz pointed out that he objected to the HMAC revised text.  

Tony indicated that the revised text is in Section 3.2 at line number 
245 (merged version) in the User Name Token Profile.  

Jerry would prefer that we prohibit the use of key derivation algorithm 
instead of saying it is out of scope and application-specific.  Irving 
(HP) agreed with Jerry. Ron M (Sun) also agreed. 

Blake D (Sarvega) originally brought up this point and stated that he 
felt it was a big interoperability problem.  Blake D felt that having 
at least one solution would be best but saying it is out of scope is 
acceptable.

Chris K pointed out that following this reasoning would suggest that 
the usage attribute should not be in the profile.

Mike M (IBM) moved to accept the text on lines 245-248 of User Name 
Token Profile.
Seconded by Blake D (Sarvega).

Vote 1 YES 

  Hal Lockhart BEA
  Guillermo Lao ContentGuard
  TJ Pannu ContentGuard
  Sam Wei Documentum
  Toshihiro Nishimura Fujitsu
  Yutaka Kudo Hitachi
  Paula Austel IBM
  Kelvin Lawrence IBM
  Anthony Nadalin IBM
  Nataraj Nagaratnam IBM
  Ron Williams IBM
  Paul Cotton Microsoft
  Vijay Gajjala Microsoft
  Chris Kaler Microsoft
  Frederick Hirsch Nokia
  Charles Knouse Oblix
  Steve Anderson OpenNetwork
  Blake Dournaee Sarvega
  Coumara Radja Sarvega
  Jonathan Tourzan Sony
  
Vote 1 NO 

  Merlin Hughes Betrusted
  Symon Chang CommerceOne
  Irving Reid HP
  Don Flinn Individual
  Bob Morgan Individual
  Prateek Mishra Netegrity
  Vipin Samar Oracle
  Jerry Schwarz Oracle
  Eric Gravengaard Reactivity
  Andrew Nash RSA Security
  Rob Philpott RSA Security
  Martijn de Boer SAP
  Pete Wenzel SeeBeyond
  Yassir Elley Sun Microsystems
  Jeff Hodges Sun Microsystems
  Ronald Monzillo Sun Microsystems
  Jan Alexander Systinet
  
Vote 1 ABSTAIN 

  Gene Thurston AmberPoint
  Thomas DeMartini ContentGuard
  John Hughes Entegrity
  Kefeng Chen GeoTrust
  Richard Levinson Netegrity
  Ed Reed Novell
  John Weiland US Navy
  Phillip Hallam-Baker VeriSig

For: 20
Against: 17
Abstain: 8

Motion carries.

Kelvin asked if there are any other issues outstanding.  Chris K noted 
that Hal L was supposed to tell us if we needed to say anything about 
SOAP 1.2.  Hal felt that this material was not necessary for 
progression.  No one on the call disagreed.

But Hal L pointed out that voting on a document that arrived last night 
is quite difficult due the large number of late changes.

Ron M indicated that he had reviewed the Issues List and had difficulty 
determining how the document has been changed in relation to the status 
of the Issues List.

Kelvin pointed out that the major technical changes were made in the 
Dec draft of the document and subsequent revised versions have had 
change bars and have been reflecting editorial changes.

Ron's email of Jan 12 pointed to the following issues:

>issue 13: Element ordering in security tag

Ron pointed the meeting to lines 856-857 in the Core Spec which has 
been pointed to by several issues and these lines still appear in the 
spec.  Issues 143 and 201 are related to this. 

Ron proposed to delete lines 856-857 which relate to key ordering.  

Tony indicated that these lines were indeed clarified in a previous 
edit. 

Tony pointed to the clarification in line 440 of the Core Spec 
(merged). Ron felt that this clarification was not applicable to his 
problem with lines 856-857. Tony pointed out that the ordering rules 
were indeed clarified.

Hal suggested that lines 856-857 could say "use the correct order" 
instead of "alter the order".

Ron subsequently agreed to leave this issue and no action was taken.


>issue 62: versioning mechanism 

Chris K pointed out the solution was to version the document/namespace 
URIs.  Ron was concerned about document versioning and runtime 
versioning.  Chris K said that a new version of a token would be 
reflected in a new document and thus the new token would be identified 
by the document/namespace URI which is already versioned. This decision 
was made at the San Francisco F2F.

Jerry asked where the User Name Token Profile demonstrates how the 
ValueType value is specified. Someone pointed to lines 239 in the User 
Name Token Profile which defines what the full URI is.

Ron agreed that the versioning information is carried in the URI.

>issue 173: "Examples use earlier versions of SOAP or early drafts of 

SOAP 1.2. Pass thru examples. Editors to make examples consistent with 
SOAP 1.1"

Chris K: All the examples were made to be in SOAP 1.1.  Hal L had an 
action to investigate whether we needed to say anything about SOAP 1.2 
and the TC felt that this was not mandatory.

Ron agreed that this issue was indeed resolved.

>issue 187 from the  W3C XMLP WG  and referring to "Two <wsse:Security> 
header blocks MUST NOT have the same value for S:role." 

Tony indicated that this is clarified on line 430 of the WS-Security 
Core spec in response to Frederick's editorial comment.  Chris K said 
we thought we had answered this by email that this rule is there to 
avoid an ordering problem.

Ron agreed that this issue has indeed been resolved but he suggested 
that the TC needs to send response emails to XMLP and the WS-I BSP.  
Kelvin said that he had sent an email explaining what happened to 
comments on Nov 11 and Kelvin asked then and again if there were any 
deficiences in his response.

[The meeting revisited this issue a second time.]

Rob pointed to minutes of the Oct 21 2003 meeting that dealt with issue 
187 which indicate that the Editor's were to add clarifying text.

Ron indicated that he would prefer that the spec specifically mention 
why two header blocks MUST NOT have the same value for the S:role.  Hal 
confirmed that this is indeed done to avoid any ordering problem.  Hal 
agreed that we agreed to add some text here.

>issue 189 the W3C XMLP WG asked how must compliant implementations 
declare the profiles they support? Did we answer this question?

Chris: Yes we answered this question and the answer there is no 
required way to declare this. 

Ron agreed with this status.

>issue 198, the W3C XMLP WG asked how section 6.4 qualifies as a 
framework?

Ron felt this item could be skipped at this time.

>issue 203 from the W3C XMLP WG asked whether "SOAP applications" is 
appropriately used in line 920, as this line is really talking about 
what a WSS implementation must do.

Ron simply pointed out this issue.
 
> issue 217 from W3C XMLP WG asked if a password equivalent should be 
password equivalent should be contained in a wsse:PasswordText or  
wsse:PasswordDigest typed Password element. 

Chris K indicated that text was added to clarify this question.  You 
can indeed do either. Chris pointed to line 171 in the Core Spec.  

Kelvin pointed out that this change was made as a result of TC 
decision.  

> issue 183 commented on, "This document defines syntax and semantics 
of signatures within a <wsse:Security> element.

No further change was requested although Ron suggested that the grammar 
of the change was not the best.
  
>issue 207 from W3C XMLP WG - "Error handling: The specification should 
define the values of the Fault/Reason/Text, Fault/Code/Value and 
Fault/Code/Subcode/Value EIIs".

Chris K pointed the meeting to lines 1488-1492 in the Core Spec.  Ron 
agreed that this dealt with this issue and no further change was 
required.

>other issues
Ron asked if we were going to review the open issues with numbers 235 
and higher.  

Issue 236 is resolved by a recent version since the offending sentence 
was deleted.

Issue 237 is resolved by a recent version which removes the backpointer 
to the security token.
 
Issue 238 was closed with no action.  The meeting agreed that no text 
for SOAP 1.2 was required.

Merlin proposed to resolve Issue 239 by ensuring that a X.509 issue 
serial element is wrapped in a X.509 data element because D-Sig was not 
going to make our requested change.    
Adopted unanimously and this changes the X.509 token profile.

Issue 240 is already closed with the lastest version.

Issue 241 (re restriction on timestamp) was dealt with on lines 1739 in 
the Core Spec but Tony agreed that a further change was required for 
the second half of the issue.

> 4. Voting (as per previous e-mail)

Chris proposed the following plan:

a) Tues and Wed to review the current documents to ensure that 
normative text in the current documents correctly reflects decisions of 
the TC

b) Thu new versions are available from the editors

c) Fri we review new versions to ensure that any subsequent changes are 
correctly done.

d) over the weekend the Editors produce a final spec

e) next week the Chairs will set up 2 Kavi votes (adopt all three specs 
as CD and then to progress them) for a period of one week.

Jerry suggested that anyone commenter should give explicit text for any 
Change they propose.

Kelvin asked if there was any objection to having just two votes 
instead of six votes (adoption+progression by three documents).  There 
was no objection to having just two votes on adoption and progression 
of the set of three specs.

Kelvin requested implementers to send email to him noting that they 
have successfully used the specification.  We will also need the IP 
statement clear per the OASIS rules.  

Kelvin will point the TC to the checklist of ten things that we must do
when we have a positive vote to progress.  See:
http://www.oasis-open.org/committees/process.php#standard 
 
> 5. Issues list status/review

See above discussion of Ron M's email on the issues list.
 
> 6. Status of other profiles/interop planning etc

Not discussed.
 
> 7. Other business

None.
 
> 8. Adjournment

The meeting adjourned at 12:00 noon EST. 
 
[1] http://lists.oasis-open.org/archives/wss/200312/msg00102.html

Paul Cotton, Microsoft Canada 
17 Eleanor Drive, Nepean, Ontario K2E 6A3 
Tel: (613) 225-5445 Fax: (425) 936-7329 
mailto:pcotton@microsoft.com

  



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