[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for Telecon, Tuesday 12 August 2003
Minutes for WSSTC Telecon, Tuesday 12 August 2003
Dial in info: 1-517-267-1044 Passcode: 502413
Minutes taken by Steve Anderson
======================================================================
Summary
======================================================================
Votes:
- Minutes from 29 July 2003 meeting accepted (unanimous)
New (General) Action Items:
- Tim to set up conference call for end of week for X509
profile discussion
- Chairs to followup with OASIS on namespace issues
Issues List Action Items & Status Updates:
- Editors to make editorial change from issue 99
- 100
- mis-marked, should be CLOSED
- 115, 120, 121, 122, 123, 124, 125
- incorporated into last versions
- CLOSED
- 127
- consensus on 2 points
- remove recommendation for exclusive c14n
- add brief discussion under interop considerations, which
can be done in public review, since interop
considerations are non-normative
- Hal to propose wording for issue 127 by end of week
- PENDING
- 128
- Tony to change example to refer to custom token rather
than username token, and to add description text
- PENDING
- 129
- Editors to remove remaining text on SOAP attachments
- PENDING
- 130
- Tim to provide clarifying text
- PENDING
======================================================================
Raw Notes
======================================================================
>
> Agenda:
>
> 1. Roll call
>
- Attendance attached to bottom of these minutes
- Quorum achieved
>
> 2. Review minutes from previous meeting (7/29/2003)
> < http://lists.oasis-open.org/archives/wss/
> 200307/msg00067.html >
>
- [VOTE] unanimous consent, accepted
>
> 3. Review outstanding actions
>
- everything has been moved to the issues list
>
> 4. Editorial updates/document status [Editors]
>
- Chris: X.509, Username & Core have been updated
- Phill: X.509 changes
- reorganized, doc now flows better
- had email from Tim this morning, seems roughly in agreement
- some changes still needed
- need to reference Merlin's signature transform
- Tim suggested we have a conference call later this week to
close these out
- [ACTION] Tim to set up conference call for end of week for X509
profile discussion
- interested parties can email Tim, and he will provide call-in
details
- Hal: suggests Thurs at 3pm EDT
- Tony posted Username & Core, and indicated that changes are done
- Ron: thought we agreed to add statement to core relating to
ValueType, stating what the default is, for keyIdentifier
- Tony apparently couldn't find record of such decision
- Hal: it is in issues list, under resolution of issue 99
- "Profiles must define what value is implied if specific value is
not specified"
- [ACTION] Editors to make editorial change from issue 99
- Hal: did have an issue to post updated spreadsheet from June interop
- has done it
>
> 5. Discussion of second interop scenarios
>
- Hal: there has been a little feedback on the draft
- will roll them into an update, hopefully published today
- Chris: people should be looking at draft, and indicating when they
can do an interop
- has about 6-8 names so far
- any additional interested parties should email Chris quickly
- interop discussion (other than IP address info) will be carried out
on main email list
- Chris: need to know when people can provide a ready date for interop
- Kelvin: intent is to do virtual version of June interop event
- Merlin: need to schedule specific days, with IRC channel open
- Chris: are the interop draft changes significant enough that we need
to see the update before providing a ready date?
- (apparently not, no responses)
- Chris: will solicit commitments on list
>
> 6. Address remaining V1 issues
>
- Version 22
- 115
- Phill: has been folded in
- CLOSED
- 120, 121, 122, 123
- all Frederick's edits
- Tony said all were incorporated
- Frederick: hasn't been able to get on to verify
- will re-raise if not acceptable
- CLOSED
- 124
- Chris: believes all done
- editors can re-raise if not
- CLOSED
- 125
- Simon's edit, should be folded in
- CLOSED
- 127
- Peter not on call, Hal trying to summarize
- Hal: seems unacceptable to require receivers to know about all
schemas in the message
- Merlin: suggests using regular, inclusive c14n
- doesn't anticipate needing to sign something that will be moved
into another context
- Phill: disagrees, does anticipate moving to different context
- Chris: is there a specific edit here?
- Hal: yes, we need to make constraints very clear
- Merlin: agrees, and there are more issues with moving signed data
into new contexts beyond c14n, e.g. ID value collisions
- Hal: we need some proposed wording, along lines of Merlin's
warning
- Ron: this only shows up with exclusive c14n, right?
- Chris: no, can show up with inclusive c14n
- Merlin: solution can be to deal with separately signed XML
documents as attachments
- Phill: suggests we punt on this, and leave it for another
committee to work on
- Merlin: suggests we not recommend exclusive c14n, and that we
advise the spec reader to only use c14n algorithms after
understanding their limitations
- plain c14n is required for XML Sig compliance
- Ron: SSTC originally recommended inclusive, but has now changed
to recommend exclusive in order to support WSS
- Chris: all our interop work has been around exclusive c14n, so
we can continue to recommend that, with proper caveats
- Merlin: disagrees, we shouldn't recommend something with such
problems
- Jeff: we can learn from SSTC's pattern
- Merlin: this is different usage environment, since the signed
material in this case is in the SOAP header rather than the body
- Jeff: then we need to include the rationale
- Ron: there is some text around this already, around line 940
- Tony: proposes that we document the challenges, as Phill
suggested
- Hal: thinks the only contention is whether we recommend a
particular c14n, and if so, which one
- Jerry: looking at exclusive c14n doc, and they intended this to
be used with signatures
- Merlin: again points out the difference in our usage vs. what
was intended with exclusive c14n
- Merlin: proposes we drop recommendation of exclusive c14n, and
that we recommend the use of an "appropriate" c14n, based on
spec reader's clear understanding of limitations of chosen c14n
- Don: are we saying that there isn't a c14n that covers all the
cases?
- Hal: yes
- Ron: we're also saying that the one we've recommended isn't the
best fit either
- Tony: disagrees, thinks we've identified limitations, but there
isn't a 'best' one
- Merlin: believes inclusive fits better
- Tony: disagrees, and will post issues with inclusive c14n
- Kelvin: can we address this during the public review?
- Merlin: yes, it's just a change to a recommendation
- Rob: cautions that substantive changes require repeating the
public review
- Hal: thinks that just saying "use an appropriate c14n" isn't
enough, thinks we need to provide description of issues around
using either inclusive or exclusive
- Chris: remaining neutral wrt c14n means inclusive must be
supported, but not necessarily be used
- John: and if another c14n algorithm emerges tomorrow, it can be
used by WSS implementations
- Ron: thinks this will impact profiles, e.g. MProf, SAML, X509
- Hal: SAML in general should still use exclusive
- Phill: X509 profile shouldn't be affected
- Ron: we're not actively working on MProf currently
- consensus on 2 points
- remove recommendation for exclusive c14n
- add brief discussion under interop considerations, which can
be done in public review, since interop considerations are
non-normative
- [ACTION] Hal to propose wording for issue 127 by end of week
- Merlin: so 2nd interop will use inclusive?
- doesn't sound like there will be time to accommodate this
- Chris: choice of c14n is an interop choice anyway, and since
we've begun with excl, continue with it for now
- could have a 3rd interop using inclusive
- Merlin: fine with that
- PENDING
- 128
- Hal: the example shows something not supported by the spec
- Ron: seems that example supports doing something cool, but
contradicts one of the non-goals of the spec
- Chris: yes, normatively defining mechanisms to identify out-of-
band keys is a non-goal, but parties are free to agree on a
mechanism on their own, and to use WSS to express it
- [ACTION] Tony to change example to refer to custom token rather
than username token, and to add description text
- PENDING
- 129
- Chris: thought we removed the attachment section
- sounds like we missed a piece
- PENDING
- [ACTION] Editors to remove remaining text on SOAP attachments
- 130
- Phill: issue is how much description about how we do encryption
belongs in core vs. X509 profile
- seems that some of the discussion is germane to any use of
encryption, not just X509
- involves interaction with multiple roles
- Hal: had concluded that this multi-party decryption scenario
wasn't feasible
- Jerry: it's totally ambiguous now whether encrypted data is
replaced by decrypted data as the message is passed along
- Chris: why would it ever be replaced?
- Hal: that seems to be a common usecase, involving intermediaries
- Chris: why would we normatively discuss that, rather than leave
that to implementations?
- Hal: current spec doesn't say what intermediaries have to do,
which is ok, but it seems odd that people are interpreting it
differently
- Chris: any objections to leaving text way it is?
- Tim: ok with that, but would like some clarifying text on what
could be expected by intermediaries
- [ACTION] Tim to provide clarifying text
- PENDING
- (new) 131: Do we have a conformance list
- related to issue 130
- post-v1.0 issue
- RESCINDED BELOW
- 31
- Chris: still waiting for OASIS
- Kelvin: pessimistic that this will get resolved in time
- Rob: concerned that it will block the spec
- Chris: thought we'd continue to use the generic address we
already have, which is guaranteed to be persistent
- Rob: in private discussion with Karl, it doesn't sound like that
will be permitted with OASIS
- they have a namespace chosen, but there's no disk space behind it
yet
- [ACTION] Chairs to followup with OASIS on namespace issues
- 100
- Jerry: mis-marked, should be CLOSED
- CLOSED
- Jerry: concerning 131/127, mandatory to implement discussion, thinks
that changing such text during public review will require another
review
- Chris: how is this outside WS-I work?
- [more discussion]
- result is that issue 131 is to be rescinded
>
> 7. V1 committee spec vote ?
>
- Kelvin: looks like we need one more rev before voting
- expectation is to have them posted by end of this week
- Phill: will be out all of next week, so all changes will be this week
- Kelvin: if we get revised versions out end of this week, can we have
a vote next week, with 7 days to vote, will that work to achieve
Committee Spec? Then, with results in hand, on next call, we can
vote to begin public review
- doc set will be Core, X509 and Username
- sounds acceptable
- Plan, restated:
- Get new versions of Core, X509 and Username docs by Friday
- Kavi votes will open beginning next week on each doc
- Voting will close after about 7 days
- On next call, we'll review voting results and consider voting to
begin public review
>
> 8. Other business
>
- none
>
> 9. Adjourn
>
- Adjourned
-----------------------------------------------------------------------
Attendance of Voting Members:
Gene Thurston AmberPoint
Frank Siebenlist Argonne National Lab
Merlin Hughes Baltimore Technologies
Irving Reid Baltimore Technologies
Hal Lockhart BEA
Symon Chang CommerceOne
Thomas DeMartini ContentGuard
TJ Pannu ContentGuard
Seshu Madabhushi Convergys
Shawn Sharp Cyclone Commerce
Tim Moses Entrust
Toshihiro Nishimura Fujitsu
Yutaka Kudo Hitachi
Kelvin Lawrence IBM
Anthony Nadalin IBM
Nataraj Nagaratnam IBM
Don Flinn Individual
Bob Morgan Individual
Chris Kaler Microsoft
Chris Kurt Microsoft
John Shewchuk Microsoft
Frederick Hirsch Nokia
Lloyd Burch Novell
Steve Anderson OpenNetwork
Vipin Samar Oracle
Jerry Schwarz Oracle
Eric Gravengaard Reactivity
Andrew Nash RSA Security
Rob Philpott RSA Security
Edward Coyne SAIC
Martijn de Boer SAP
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 Observers or Prospective Members:
Howard Melman Novell
<< awaiting email >>
<< awaiting email >>
Membership Status Changes:
Derek Fu IBM - granted voting status after call
Howard Melman Novell - granted voting status after call
--
Steve
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]