[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 03-12-16 draft minutes
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
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]