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: 03-12-16 minutes - revised [Ver2]


Attached are the minutes from 16 Dec 03, revised to include the attendance information.

regards, Frederick

Frederick Hirsch
Nokia Mobile Phones


 
WSS TC bi-weekly meeting conference call
Tuesday, 16 December 2003, 07:00am to 09:00am Pacific Time 

Minutes - Frederick Hirsch

Agenda: 
1. Call to order, roll call  
2. Reading/approving minutes of last meeting (Dec 2nd)  
3. Status of documents (Editors) 
4. Issues list review  
5. Status of other profiles/interop planning etc 
6. Other business  
7. Adjournment 

Attendance of Voting Members  
 
  Gene Thurston AmberPoint
  Frank Siebenlist Argonne National Lab
  Merlin Hughes Baltimore Technologies
  Peter Dapkus BEA
  Hal Lockhart BEA
  Davanum Srinivas CA
  Thomas DeMartini ContentGuard
  Guillermo Lao ContentGuard
  TJ Pannu ContentGuard
  Sam Wei Documentum
  John Hughes Entegrity
  Tim Moses Entrust
  Toshihiro Nishimura Fujitsu
  Kefeng Chen GeoTrust
  Jason Rouault HP
  Yutaka Kudo Hitachi
  Derek Fu IBM
  Kelvin Lawrence IBM
  Anthony Nadalin IBM
  Nataraj Nagaratnam IBM
  Don Flinn Individual
  Paul Cotton Microsoft
  Chris Kaler Microsoft
  Ellen McDermott Microsoft
  Richard Levinson Netegrity
  Prateek Mishra Netegrity
  Frederick Hirsch Nokia
  Abbie Barbir Nortel
  Lloyd Burch Novell
  Charles Knouse Oblix
  Jerry Schwarz Oracle
  Eric Gravengaard Reactivity
  Martijn de Boer SAP
  Blake Dournaee Sarvega
  Coumara Radja Sarvega
  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
 
  Andrew Nash RSA Security
  Paula Austel IBM
  Maryann Hondo IBM
  Ben Hammond RSA Security
  David  Orchard BEA Systems
  Kevin Lewis Documentum
  Ramana Turlapati Oracle
  Rich Salz DataPower
  Gevenraj Sodhi CA
 

Membership Status Changes
 
  Andrew Nash RSA Security - Granted voting status after 12/16/2003 call
  Paula Austel IBM - Granted voting status after 12/16/2003 call
  Senthil Sengodan Nokia - Requested membership 12/2/2003
  Jagdip Talla Crimson Logic - Requested membership 12/8/2003
  Ramana Turlapati Oracle - Requested membership 12/10/2003
  Howard Melman Novell - Lost voting status after 12/16/2003 call
  Vijay Gajjala Microsoft - Requested LOA 12/1/2003
  John Shewchuk Microsoft - Requested LOA 12/2/2003

Meeting Summary
1. Minutes from last meeting (Dec 2) approved.
2 Pending items that have resolution in latest draft from editor moved to closed - editor confirmed on call.  Without objection.
3 Motion passed -  
"Replace all occurances of QNames in valuetype and encoding type  with a URI, also replace QName usage attribute in SecurityTokenReference with 
list of URIs"

4 AI Editorial action to update next version of core, schema  and token profiles to take into account above motion.
Issue 195 and 196 move to pending

5 AI - Kelvin to follow up on number from Oasis staff for URIs
6 New Issue: Need to update SAML, X509, Kerberos specs with new URL 
7 Issue : At document vote one last pass to update dates and numbers in all documents
8 AI Chairs to follow up with Irving and determine status for issue 239

9 Resolution -  drop valueType attribute in timestamp - see http://lists.oasis-open.org/archives/wss-comment/200310/msg00022.html

10 AI Editors to update core to drop valueType from timestamp and require ds:DateTime

11. Editorial revisions should be out by this weekend, comments and review before next call, Jan 13, should be able to stay on schedule.

12. Hal to bring back to WS-I BSP view that if security header timestamp is too old, fault should be returned.

13. Deferred Issue - can there be multiple timestamps in security header

14. Next call in January 13, everyone should have reviewed everything, any issues posted to list. Goal is to vote on documents at next meeting.

15. Paul Cotton volunteers to be secretary on next call if needed.

-Kelvin - Thanks to those who offered to sponsor the call.

1. Call to order, roll call 
39 voting members present, 27 required for quorum, have quorum.
2 people remain on leave
 
2. Reading/approving minutes of last meeting (Dec 2nd) 
No corrections or objections. Minutes approved

Hal - would like to add item to agenda
Kelvin - time during other business portion of agenda.
 
3. Status of documents (Editors)
SAML - Ron posted SAML token profile update today, version 8, not complete 
but has many changes. QName and ValueType issues may still require additional 
changes. Next update planned after issues get resolved (196 and others), after the 
holidays.
Phillip - no changes, awaiting URL and Merlin sign off on his issues.
Tony - posted Username token profile, an additional update to be made with 
Isymura comments, last comments received. Please send comments immediately
Posted core update, listed closed items and open items in posting, saw posting 
from Frederick, waiting on input from Hal 
 
4. Issues list review 
Issues List #30, 
http://www.oasis-open.org/apps/org/workgroup/wss/download.php/4436/wss-issues-30.htm

Propose to close Pending items that the editors have resolved, re-open if 
necessary. Closed items confirmed by editors
No objection

Issue 31 - agreed on last call to Kelvin's proposal, mark closed. Kelvin to go back 
to Oasis and find out number.
Kelvin - Numbering system is being used, so sent mail to Oasis to get number. 
Number assigned at end, so trying to get number ASAP. Need to send follow-up, 
been two weeks.
AI - Kelvin to follow up on number. 
New Issue: Need to update SAML X509, Kerberos specs with new URL 
Issue : At vote one last pass to update dates and numbers.
82 - mark closed, assuming proofread of docs.
127 - closed
133 - closed
135 - rename doc files, close, open issue for each document 
136 - editorial portion closed, other question regarding BinarySecurityToken 
element vs CustomToken element, maybe previously checked.
Tony to review.
 
137 - closed in latest username
138 - closed
143-146 closed
147-155 closed
156-163 closed with latest version
166 closed
167 closed
168 closed
169 closed
171-176 closed
177-184 closed
185-190 closed
190-192 closed
194 pending some additional changes
195, 196 will discuss on call
197-199 closed
200-202 pending
203 closed
204 pending
205-6 closed
207-8 pending
209-220 username token, closed
221-229 x509 token, closed
230 231 233 closed
234 SAML, waiting 196 issue
235 - 238 pending 
239 Pending
Phillip Has Irving request been made to XML Dsig, has it been accepted?
AI Chairs to follow up with Irving and determine status
Rich - Dsig exists to publish errata, so this would be legal change, so worthwhile 
for Irving to ask
240 Pending
New issues to be added?
Hal - Dave Orchard issue?
Chris 195, 196, Encoding type and Qname
Hal - meant timestamp issue
Chris - new issue
Overview of new issue:
Timestamp has value type to allow format other than xs:dateTime, doesn't allow 
schema checking, proposal to required xs:dateTime.
Tony - Cases to use existign timestamp that doesn't fit schema format
Ron - can't convert when putting into XML wrapper?
Who is responsible sender or receiver?
Sender should convert
Tony Sender might not be able to
Ron Receiver has to convert to form they understand
Tony they might understand it
Don Stretch that not able to convert it 
Tony Why be forced to convert?
Ron Bridging old technology
Tony Using as transport, Don't want to be forced to convert
Ron want to convey universal format, not unreasonable, gives extensibility to 
allow everyone to interpret time format. Can one ignore all forms other than 
xs:dateTime
Hal - have no defined conformance criteria
Ron - are you required to understand timestamps, thought so
Hal - must follow what expires says, implies need to understand time
Ron - doesn't seem reasonable to process expires semantic to understand every 
possible timestamp format
Don - sender only needs to understand their own 
Lloyd (Novell) - would required everyone to understand every format or reject 
messages
Jerry - Tony could create his own token to convey his own timestamp - not 
standardized semantics
Ron - alternative is no semantics, not useful
Chris - where do we stand?
Tony - could introduce new fault...
Frederick - should we consider common form proposal?
Lloyd - Make common case simple, make hard case possible...
Frederick - Tony are you proposing that upon receiving Fault you convert?
Tony - that could be one case, or not handle it
Lloyd - best case to convert is on sender side, least case on receiver side, since 
sender knows, Could put both in message, converted and unconverted. This would 
allow additional info to be conveyed when not all converted, but processing rules 
based on standard form. Receiver could look inside extension if knows about it. 
All other apps would use XML timestamp, but receivers that understand legacy 
timestamp could use it and choose to ignore xml timestamp.
Tony - makes it hard
Chris - how
Chris - Proposal - Drop value type and convey standard type. 
Tony - ok with this
David Orchard - what I proposed
New issue - update core with this change
Discussion 195, 196
Chris - New data suggests discussion appropriate, even though closed earlier
Hal - Many arguments for not using QNames 
Chris - where is QName bad
Hal - apart from canonicalization
Chris - need summary of issues
Tony - canonicalization discussed in core, precautions mentions 580
Paul Cotton - What are those precautions?
Chris do not require exclusive, recommend inclusive
Hal if you use exclusive, practical choice, if declaration out of signature range, 
namespace declaration 
Frederick - opens risk to all implementations
Paul Cotton - why doesn't apply to any QName
Ron - QNames in security token references biggest concern
Hal - two cases, valuetype and encoding type, not a problem for element
Paul - what does canonicalization do with start tag when prefix not in context?
Rich - has to be in scope
Rich - can't canonicalize element independent of namespaces in scope at that 
moment, add namespace declaration to outermost element.
Paul - why a problem
Rich - don't know to do that for attribute values
Paul - schema validation and canonicalization are not in sync
Paul - so are warnings in spec enough, or should we make technical change
Jerry - valuetype and encoding type appear in many places, shouldn't warning be 
applied at all places
Chris - confusing about using URI, given previous email from XML protocol 
group suggesting using xsi:type, a QName. Inconsistency here.
Only one value given, for extensibility, so why do the extra work, if you add the 
new type, should be able to check type.
Steve Orchard - Implies coupling of software, signature and canonicalization 
Paul - can achieve by making sure no prefixes present to avoid problem - resolve 
prefixes
Steve - what does this mean?
Paul - do the resolution in the software.
Steve - various implementations, this would be an out of band agreement, want 
interoperability
Tony - can have interoperability problems either way
Chris - what is the interoperability problem
Tony - value of an encoding type, either uri or qname, will do whatever is needed 
to support that
Security risk - canonicalization may not capture namespace properly for attribute 
value
Rich - canonicalization is not schema aware - 
Paul - is there one
Rich - one from UDDI, but not going forward
Merlin - canonicalization must be configured with namespace
Paul - what is wrong with this as solution for these two attributes
Frederick - every application would have to implement this correctly
Merlin - would have to scan, a lot of work
Hal - applications would know about these QNames
Phillip - only see problem if signing QName with prefix not visible. Trying to fix 
XML is wrong. Can fix it by introducing dummy attribute, whenever you use 
QNames either explicitly declare schema or reference dummy attribute.
Jerry - problem with any rule that requrie namesapce declarations in specific 
places , processing should be able to move at will
Frederick - independent layers might not allow knowledge of QName attributes 
and thus require scanning and processing.
David - issue way to tell canonicalization have namespace declaration, adding 
constraints on where namespace declarations should occur.
Paul - this is what dsig is says what to do to make canonicalization work
David - dsig says what you can do, spec gives rationale, earlier statement said that 
problem is that common way of building XML software does not occur this way, 
saying how software is made
Paul - people are ignoring dsig, then complaining about WSS use of QNames
Jerry - No, XML rules say you can move XML namespaces creating equivalent 
XML
Paul - this is orthogonal. If you don't follow XML rules, get in trouble
Hal - not the case, need external information about namespace you are using. Start 
avoiding using QNames in attributes
Paul - slippery soap
Rich - signing entire body often, so general QNames not the issue. Can remove 
the risk all together here in WSS, making simpler, remove limitations on 
implementations, security concerns, interoperability concerns.  Make hard to use 
general signing mechanisms. Can't easily write XPath expression searching for 
the token types.
Frederick - why not follow TAG finding to not use QNames for attributes, isn't 
this an opportunity to make the change before versioning
Rich - can remove unnecessary risk?
Hal - using URIs in SAML
Tony, Phillip - call for vote
Tony motion - vote to accept QNames as currently written in document
Jerry - not well-formed motion, need to propose change. Replace all occurances 
of QNames in valuetype and encoding type with a URI.
Ron - Second, friendly ammendment, also replace all occurances of usage 
attribute in SecurityTokenReference with list of URIs
Jerry - accepted.
Hal - vote is not on exact wording
Vote Motion:  Replace all occurances of QNames in valuetype and encoding type 
with a URI, also replace QName usage attribute in SecurityTokenReference with 
list of URIs
Paul - use # like XMLDsig (or /)
Jerry - form of URI
Chris - different ways using QNames, to be consistent with DSig, need rules when 
use URI and when QName, DSig uses URIs for algorithm. Tony has friendly 
ammendment to define rules.
Ron - Paul referred to something Rich had responded.
Rich - DSig defines base uri then fragment identifiers. Determining form of URIs 
is secondary
Hal - does dsig use qnames as identifiers
Rich No
Chris - dsig uses uris for algorithms
Merlin type is uri for retrieval algorithm
Frederick - do not understand Tony's ammendment
Jerry - neither do I, not accepted.

role call vote
19 Y, 8 N, 2 abstain (is 27 which is quorum)
Motion is carried.

AI Editorial action to update next version of core, schema  and token profiles.
Issue 195 and 196 move to pending

Kelvin - should discuss impact on schedule
Need changes between now and January 13 and also review
Chris - this will require editorial work, but if we get out by weekend, can still be 
on schedule.
 
5. Status of other profiles/interop planning etc
SAML 
Rich Levinson - put out SAML interop spec, have not received any comment on 
updated spec (based on comment from Ron). Are there any significant changes to 
SAML token profile impacting interop?
Ron - No, none should impact it, apart from issue 196 today
Rich - scheduling after closure of spec, willing to schedule
XrML - No update, good for people to start thinking about it. Would like to have 
sometime in Jan or Feb, depending on people. Update in January.
 
6. Other business 
Hal - issue regarding semantics of timestamp, in particular relating to encryption. 
Only related to authentication?
http://www.oasis-open.org/archives/wss/200312/msg00075.html
Hal e.g. Do not decrypt if too old?
Jerry - what if intermediaries add timestamps?
Hal - an additional issue, can only have one timestamp per security header
Ron - if someone includes timestamp and only encryption , should timestamp 
have significance, whether we can attribute significance should not matter - not 
necessarily relate to signature or encryption
Jerry - timestamp applies to header as a whole, so header should be discarded if 
timestamp is too old
Hal any objection to view, if timestamp expired discard message regardless?
No objection.
 
      7. Adjournment 

Chris - Next call in January 13, everyone should have reviewed everything, any issues 
posted to list. Goal is to vote on documents at next meeting.

Kelvin - looking for volunteers for January 13

Paul - volunteers to be secretary

Additional role - none
 
Meeting adjourned.
----







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