[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for Telecon, Tuesday 15 July 2003
Minutes for WSSTC Telecon, Tuesday 15 July 2003
Dial in info: 1-405-244-5555 Passcode 6921
Minutes taken by Steve Anderson
======================================================================
Summary
======================================================================
Votes:
- Minutes from 1 July 2003 meeting accepted (unanimous)
New (General) Action Items:
- (none)
Issues List Action Items & Status Updates:
- 67: change from PENDING to OPEN, but for post-v1
- 84: CLOSED for v1 (keeping current approach), OPEN for post-v1
- Hal to start email discussion
- 99: Hal to review, and send email to editors if ok
- 111: CLOSED
- Kelvin to update contributors list and forward to editors
- 112: CLOSED, Tim satisfied
- 115: PENDING, conclusion is that profiles are rev'ed independent
of the core spec AND of the underlying spec being profiled (e.g.
X509v3 -> X509v4)
- 117: CLOSED, DUPLICATE of 115
- 118: CLOSED, consensus around leaving text as is, recommending
PKIPath, but allowing PKCS7
- 119: CLOSED, previously decided in Baltimore F2F to move out of
core
- 120: PENDING editorial text
- Frederick will provide this text
- 121: PENDING editorial text
- Frederick will provide this text
- 122: PENDING editorial update
- 123: PENDING editorial update
- 124 (new):
- boilerplate intro not necessary in each profile, specifically
identification/contact info, description and updates
- editors to remove 4 bullets in boilerplate intro of each doc
- PENDING
======================================================================
Raw Notes
======================================================================
>
> Agenda:
>
> 1. Roll call
>
- Attendance attached to bottom of these minutes
- Quorum achieved
>
> 2. Review minutes from previous meeting (07/01/2003)
> < http://lists.oasis-open.org/archives/wss/
> 200307/msg00015.html >
>
- [VOTE] unanimous consent, accepted
>
> 3. Review outstanding actions
>
> - Hal will update interop spreadsheet based on emails sent
>
- Hal: hasn't done this yet
>
> - Chris to coordinate interop contact names list
>
- Chris: has about 3-4 company names listed, so keep the entries
coming
>
> - Chris and Kelvin to compile lists of contributors and post [Done]
>
- Kelvin: only had about 3 email so far from the initial list he
posted a week or so ago
- will post another draft later this week
- if no more responses, will assume the list to be acceptable
>
> 4. Editorial updates/document status [Editors]
>
- Kelvin: if you wrote an email within the last week or two that
might be interpreted as an issue, make sure it is brought to our
attention
- Tony: will have another draft by this Friday
- Kelvin: leaves for vacation next Tues, returning Aug 11
- Tim: status update on SAML profile?
- Ron: v7 was posted
- has a v8, but changes are very small
- Tim: is v7 in doc repository?
- Ron: thinks so
- it's harder to find, under profiles section
- you only see the first 5, then you have to click the plus sign
- Kelvin: you may need to login to OASIS site as a member to see it
- will doublecheck whether it was posted with public access allowed
- Ron: will verify/correct now
- v7 was posted May 5th
- hasn't been updated to include all contributors
- Don: we're concentrating on 3 profiles now, and it seems that to
accept a profile, we'd need an interop event
- is this being considered?
- Ron: yes, both by folks here and in SAML TC
- could be a virtual interop
- personally very busy, so hasn't been able to work on this area
- would like for someone to suggest some interop scenarios to get
it going
- Prateek: could cross-post to SAML TC
- Hal: could build on X509 scenarios
- Kelvin: at F2F, there was clearly interest in SAML profile
- Hal: doesn't want to see discussion split between here and SSTC
- would rather keep it here
- Ron: ok, same people are involved in both
- Kelvin: Ron will start a discussion, and spec will suggest when
an interop exercise is appropriate
>
> 5. Discussion of second interop scenarios
>
- Hal: apologizes for delay, hopes to publish first draft
- Chris: once we see doc and get sense of how much work it will
involve, we can begin planning event
- Hal: verifying that it's planned to be virtual
- confirmed
>
> 6. Address remaining V1 issues
>
- Chris
- 31: OASIS namespace
- still waiting on OASIS to come up with namespace direction
- Jamie: they are doing it, but not sure whether it will be
tomorrow or in Q3
- you can use the note space on your TC home page for
persistent doc posting
- Hal: didn't think that persists permanently, say after a TC
disbands
- Jamie: that's true, it wouldn't suffice for schemas
- we'll take this offline
- 62: versioning
- just waiting for draft with updated text
- 67: usage labels
- already marked pending
- waiting for Hal, after interop doc, to post
- Hal: 'pending' is an overstatement
- mark as OPEN, but for post-v1
- 69:
- pending
- waiting for updated spec
- 74:
- pending
- waiting for updated spec
- 82:
- stays open until we're done
- 84:
- Hal: owes new text
- plan is we'll allow transform, and have headers indicate
order
- will have text for Tony to go into next version
- Tony: doesn't understand how we can handle ordering of
multiple header blocks without transform
- [not clear that there's consensus on this]
- Hal: doesn't decr transform have to appear in the header?
and if the header isn't targeted for me, I don't care, right?
- Ron: is it possible to have >1 header to same receiver?
- Hal: yes, but you're supposed to process headers one at a
time
- Don: what is the order in that case?
- Hal: not clear
- Tony: what's being presumed here is the sender knows the
entire msg path
- Hal: only applies when there are overlapping encr/sigs
- agrees that this is a difficult case, but some things just
aren't possible, even with a transform
- Ron: why can the sender know the necessary order that
sig/encr was performed?
- Hal: sender does know, but the path of receivers may be
dynamic, as Tony points out
- Frederick: is this a common case that we need to allow for
right away?
- Hal: no one knows for sure
- Rich: SOAP dictates you collect all headers applicable to you
and process them, without any ordering specified
- Hal: so you treat multiple headers targeted to you as a
jumble?
- Rich: yes
- Tim: so we could prohibit super-encryption
- Hal: no, we want to allow that
- thinks that introducing decr transforms requires receiver to
scan whole msg for transforms, breaking the linear processing
model
- Tony: thinks we can't reach conclusion, proposes we postpone
until after v1
- Tony: points out that transforms are optional
- Hal: optional for who? certainly for sender, but for
receiver too?
- Paul: can you achieve interop without knowing what the
receiver must be capable of?
- Chris: sounds like people are trying to understand scenario
better, and Tony is suggesting we move this issue to V2,
keeping current approach for V1
- Hal: not clear what is current approach?
- Tony: ordering is permitted but not mandated, and one can
use decryption transforms
- Irving: any sender that will put >1 transform in separate
headers, addressed for different roles, will have to know
the order that the roles will act, or there is no control
over how the message will transform along the path
- Don: it's not just the initiating entity, it's any
intermediary
- Ron: too easy to have an unanticipated 'next' entity take
action, disrupting the necessary sequence
- Chris: maybe we should move this to the list for more
thorough discussion
- Hal: sympathetic to keeping current approach, just concerned
about possibly locking ourselves into a tough position with
initial version
- Steve: clarify optionality of decryption transform --
optional on sender, but sender must understand
- Tony: yes, but sender could also reject if transform added
- [ACTION] Hal to start email discussion on issue 84
- 90:
- pending
- awaiting new version
- 99:
- pending
- awaiting review
- was Hal supposed to send text to Tony?
- Tony: was taken care of, is in current draft,
- [ACTION] Hal to review, and send email to editors if ok
- 104/105:
- pending
- awaiting new version
- 105 (second part)
- Hal: need real cryptographers to analyze
- Merlin had pointed out that this may be a phony issue
- 109:
- pending
- awaiting new version
- 111:
- Kelvin: already posted, discussed, just awaiting any further
corrections
- will post update later this week
- CLOSED
- will hand list to editors
- [ACTION] Kelvin to update contributors list and forward to
editors
- 112:
- Tim: comfortable closing issue
- CLOSED
- 113:
- Hal: did this
- Tony: will be in next draft
- PENDING
- 115:
- Jerry: this is same as earlier issue, but needs to be done
for each doc
- Ron: hasn't done this for SAML profile either
- Tim: hasn't heard from Phill whether he's agreed to adding
versioning to initial doc (rather than in subsequent docs)
- Jerry: concerned that external profile writers, who will
follow our first example, won't provide for versioning
- Tim: conclusion is that profiles are rev'ed independent of
the core spec AND of the underlying spec being profiled (e.g.
X509v3 -> X509v4)
- this should be stated in the docs
- Ron: is valueType an optional attr even with this change?
- Chris: yes, according to syntax, but a profile could require
it
- PENDING
- 117:
- same issue as 115
- DUPLICATE, CLOSED
- 118:
- Chris: thought we agreed at F2F that we'd allow both, but
recommend PKIPath
- should be closed, just need to add this note
- Ron: does everyone have to support both?
- Chris: no, you can choose what you support
- Tim: if you support the X509 profile, you have to allow for
either
- Frederick: text says one SHOULD be used, and the other MAY
be used
- Jerry: text needs to say what MUST be supported for
conformance, and anything else is an extension
- Chris: all of our work has optional parts
- seems silly to have 3 profiles, only varying by 1-2 sentences
- [more discussion]
- basic concern is that this allows the possibility of two
completely conformant implementations not being interoperable
- consensus around leaving text as is, recommending PKIPath,
but allowing PKCS7
- CLOSED
- 119:
- Chris: we had this discussion in Baltimore F2F, and we
deliberately moved them out
- CLOSED
- 120:
- Hal: Gene Thurston had excellent response email
- there is text describing how to do this in the interop doc
- Frederick: some editorial text would be sufficient
- Frederick will provide this text
- PENDING
- 121
- Frederick: will provide clarification text here as well
- PENDING
- 122:
- Frederick: spec isn't explicit, so it's not clear
- Hal: it should be wsu:Timestamp
- needs editorial update
- PENDING
- 123:
- simple typos
- needs editorial update
- PENDING
- others?
- Frederick: not sure we need the boilerplate intro stuff in
each profile, specifically identification/contact info,
description and updates
- e.g. X509 profile, draft 5, section 3, lines 81-86
- in SAML profile as well
- Hal: would support striking those 4 items
- Chris: we can just agree to remove this
- [ACTION] editors to remove 4 bullets in boilerplate intro
- Chris: we should have all changes ready by Friday
>
> 7. How close are we to a committee spec vote ?
>
- Kelvin: best case scenario is we'll get new drafts Friday, give TC
members about a week to review, then vote on CS status (via email
ballot)
- so we're aiming for CS status email vote to open end of next week
and close by next call (29 July)
- in parallel, Hal is helping drive to 2nd interop
>
> 8. Other business
>
- OASIS interop opportunity
- OASIS has opportunity to do public interop activities at XML 2003
conference
- Dec 6-7 in Philadelphia
- we should have an OASIS standard by then
- Jamie: trying to is find bring together standards to show interop
- we have done one-off interops
- but to understand value prop, need to show 3-4 standards
working together solving a business function
- looking for suggestions, either through your chairs or directly
to Jamie
- Jamie also getting pressure from EEMA
- conference being held Oct 7-9 in Vienna
- doesn't look like this timeframe fits this TC's schedule
- but they're very persistent about wanting a security-based TC
to perform some demonstration
- so we're posing the question to the TC once again
- send any thoughts again through chairs or directly to Jamie
- Kelvin: December event looks very attractive
- October looks more difficult
- have been focused on non-public activities
- Hal: October event could be more prohibitive due to travel
- Jamie: in EU, there are political conditions creating big need for
direction from an organization like ours
>
> 9. Adjourn
>
- Adjourned
-----------------------------------------------------------------------
Attendance of Voting Members:
Gene Thurston AmberPoint
Merlin Hughes Baltimore Technologies
Irving Reid Baltimore Technologies
Peter Dapkus BEA
Hal Lockhart BEA
Symon Chang CommerceOne
Thomas DeMartini ContentGuard
Guillermo Lao ContentGuard
TJ Pannu ContentGuard
Shawn Sharp Cyclone Commerce
Sam Wei Documentum
Tim Moses Entrust
Toshihiro Nishimura Fujitsu
Jason Rouault HP
Yutaka Kudo Hitachi
Maryann Hondo IBM
Kelvin Lawrence IBM
Anthony Nadalin IBM
Nataraj Nagaratnam IBM
Don Flinn Individual
Paul Cotton Microsoft
Vijay Gajjala Microsoft
Chris Kaler Microsoft
John Shewchuk Microsoft
Prateek Mishra Netegrity
Frederick Hirsch Nokia
Senthil Sengodan Nokia
Ed Reed Novell
Charles Knouse Oblix
Steve Anderson OpenNetwork
Vipin Samar Oracle
Jerry Schwarz Oracle
Andrew Nash RSA Security
Rob Philpott RSA Security
Peter Rostin RSA Security
Edward Coyne SAIC
Martijn de Boer SAP
Jonathan Tourzan Sony
Yassir Elley Sun Microsystems
Ronald Monzillo Sun Microsystems
Don Adams TIBCO
Attendance of Observers or Prospective Members:
Rich Salz Data Power
Howard Melman Novell
Jamie Clark OASIS
Membership Status Changes:
Mark O'Neill Vordel - Granted voting status after call
John Hughes Entegrity - Lost voting status due to inactivity,
requested re-instatement
--
Steve
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]