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: 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


    - 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
    - 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

>    - 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
- 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
        - 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 
        - 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 
        - 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 
        - 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
        - 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 
        - 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
        - will post update later this week
        - CLOSED
        - will hand list to editors
        - [ACTION] Kelvin to update contributors list and forward to
    - 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
        - PENDING
    - 117: 
        - same issue as 115
    - 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
        - 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
- 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
    - 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


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