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 20 May 2003

Minutes for WSSTC Telecon, Tuesday 20 May 2003
Dial in info: 1 (309) 495-0763 Access Code: 7224370
Minutes taken by Steve Anderson


    - Minutes from 6 May 2003 meeting accepted (unanimous)
  New (General) Action Items:
    - none

  Issues List Action Items & Status Updates:
    - 30: 
        - [ACTION] Editors to reference text from core-12, lines 168-
          174, in all docs
        - PENDING
    - 46:
        - CLOSED
    - 69: 
        - [ACTION] All profile editors to explain how key identifier is
          used for that token type, if at all
        - PENDING
    - 70: 
        - [ACTION] Eric will start discussion thread on AI-70
    - 72: 
        - [ACTION] Hal to start discussion thread on AI-72
    - 73:
        - [ACTION] Editors to make a proposal for AI-73
    - 74: 
        - [ACTION] Hal to propose text for AI-74
    - 80:
        - PENDING
    - 81:
        - CLOSED
    - 84: 
        - [ACTION] Hal to propose text for AI-84
    - new: multiple recipient email (Hal)
        - CLOSED
    - new: complaint with interop example 2
        - CLOSED
                             Raw Notes

> Agenda:
> 1. Roll call

- Attendance attached to bottom of these minutes
- Quorum achieved

> 2. Review minutes from previous meeting (5/6/2003)
>    < http://lists.oasis-open.org/archives/wss/200305/msg00026.html >

- [VOTE] unanimous consent, accepted

> 3.  Interop/F2F logistics update

- Chris: decided on San Fran on last call
- looking at downtown Hyatt
- Mon (9 Jun) noon to Thurs (12 Jun) noon
- we'll know more in a day or two
- will send out info when available
- trying to make sure we have net access
- hold off making hotel reservation until we get it nailed down, but
  can book flights now
- if anyone has food allergies/requirements, send to Chris
- Kelvin: will update Kavi calendar with info when available

> 4. Interop scenarios updates  [Hal]

- Hal: posted new version last night
- changes were slight
- there was an issue with SOAP:mustUnderstand equaling 1 vs. true in
  SOAP 1.1
- decided it's preferable to leave keyUsage out entirely
- however, some CAs insist on it
- a few more cut & paste errors have been found and will be fixed
- need suggestions on error reporting
- this is version 03, and was only posted to mail list
- Kelvin: will post to Kavi
- Hal: interested in input on whether and how to specify errors
- there were 2 other items, which will result in changes to core spec,
  which will be reflected shortly
- there didn't seem to be any interest in his multi-party encryption
- there were some subtleties around encrypting passwords
- fairly stable
- Chris: will gen a couple certs and send to list
- Hal: there was in issue for Chris on providing additional schema ****
- Chris: did forget application schema, will send out shortly
- Kelvin: there were cases where "XX" was in the absolute URIs
- Chris: those have been changed, all will reflect 2003/06
- Hal: who is bringing network hardware, DNS, etc for the interop?
- Chris: it is his goal to provide lots of that

> 5. Any editorial updates/document status [Editors]

- Phill: revised X509 draft quite substantially, accounting for Tim's
- in orig doc, it just said 'put X509 cert in'
- now can put in PKCS 7 blobs
- also, if you encrypt the message, you don't need to send the entire
  cert to validate the key, can just send issuer and serial num of key
- several cosmetic changes
- more info in introduction
- main changes are to section 3.3, specifying 3 ways of identifying
- problem with identifying a cert path
- PKIPath is not a standard yet, & no info on when it will
- not widely supported
- Ron: thought that it was an official part of X509 v4
- Tony: yes, we validated it before
- Phill: then I'll remove PKCS7
- Chris: why remove PKCS7?
- Phill: doesn't do what we want to do
- allows for any order, and for more certs than are in a path
- has an additional, unnecessary signature
- PhilG [partially disagrees/agrees]
- direction is to allow both, but recommend PKIPath
- Phill: for identifying cert by reference, this is logically a STR,
  but couldn't get syntax to work
    - e.g., for sending an encrypted message, just need to reference
      the cert
    - Chris: would have expected to have an encrypted key inside the
      Security header, and would have keyInfo within that encrypted key
    - [more discussion, including key identifiers]
    - if there is a SKID (security key identifier) present in the cert,
      you may use that, otherwise use the issuer and serial number
    - Ron: asking about usecase, which is when we're not sending the
    - Chris: thinks what's in 3.3.3 is fine, but need to also specify
      what it means for this token type if you specify a key identifier
    - proposes if people have ideas, send them to Phill, and Phill can
      produce another draft for discussion

> 6. Discussion of open issues, review latest issues list

- Kelvin: hasn't seen an update from John
- can continue on last call's issues list
  < http://www.oasis-open.org/archives/wss/200305/msg00021.html >
- don't recall where we ended
- Chris: starting at top
    - 30: 
        - Chris: supposed to have discussion with editors
        - Hal: if people take a look at core-12, lines 168-174, he's
          satisfied with these
        - Chris: thinks we need to get these into all docs
        - Jerry: suggests all profiles refer to this rather than
          duplicating it
        - Chris: great idea
        - [ACTION] Editors to reference text from core-12, lines 168-
          174, in all docs
        - PENDING
    - 31:
        - Kelvin: Karl Best is attempting to resolve them within 1-2
        - still open
    - 46:
        - Hal has sent mail to list
        - CLOSED
    - 62:
        - Ron: thinks he did this
        - proposal was to include another attribute on STR to identify
          profile & version, using URNs
        - Chris: doesn't remember proposal, were there responses?
        - Ron: Tim commented that he thought it covered the necessary
          < http://www.oasis-open.org/archives/wss/200304/
            msg00044.html >
        - Chris: everyone should look at this & we'll discuss it on 
          next call
    - 67:
        - Hal: proposed bunch of different semantics
          < http://lists.oasis-open.org/archives/wss/200305/
            msg00008.html >
    - 69: 
        - we've made progress already today
        - [ACTION] All profile editors to explain how key identifier is
          used for that token type, if at all
        - PENDING
        - Hal: interesting, how would that apply to Kerberos?
        - Chris: for that case, explanation could be to not use them
    - 70: 
        - Eric: when should a processor decide when it doesn't
          understand a security header?
        - Chris: are there objections to interpreting a mustUnderstand
          on the Security header as applying to all subelements?
        - Jerry: that seems overly strong, such as when I only need to
          understand enough to authenticate the message
        - Chris: mustUnderstand is described to require receiver to 
          understand enough to carry out its semantics, and if authN is
          the extent of your semantics, then that fits
        - Irving: good example is a mustUnderstand on a Security header
          that includes a SAML token, which has advice
        - advice may be ignored, so the mustUnderstand shouldn't 
          necessarily propagate to sub elements
        - Chris: try this - mustUnderstand applies to direct child
        - [discussion]
        - could just require receiver to abide by the standard
        - Chris: suggests starting a thread of discussion on list
        - [ACTION] Eric will start discussion thread on AI-70
    - 71: 
        - Hal: will get something out shortly on that
    - 72: 
        - Hal: timestamp trace seems ill-conceived
        - if people's clocks are synch'ed, everything's fine
        - if they're not, can't distinguish latency from skew
        - Chris: there are a number of uses beyond this
        - Kelvin: would examples help
        - Hal: yes
        - [ACTION] Hal to start discussion thread on AI-72
    - 73:
        - Tony: nothing added to docs on this yet
        - Jerry: more than just clarification, we need to decide what
          can go in there
        - originally wanted to allow anything in here that could go
          under the Security header, but that wasn't well received
        - [ACTION] Editors to make a proposal for AI-73
    - 74: 
        - [ACTION] Hal to propose text for AI-74
    - 75: 
        - Jerry: had sent a msg to list, can send another
    - 76-79:
        - have all been marked PENDING
        - Tim: will have a chance to review in beginning of June
        - Phill: will consult with Carlisle
    - 80:
        - Phill: incorporated into latest draft
        - PENDING
    - 81:
        - can be CLOSED
    - 82:
        - Kelvin: Tony did a good first pass
        - need to now double check with XML Encrypt & Signature have
        - leave open
    - 84: 
        - Chris: saw Hal's mail, and was fine
        - [ACTION] Hal to propose text for AI-84
    - 86: 
        - Chris: with interop activity, hasn't read thoroughly
        - proposes we leave it open
    - 87: 
        - still open
        - Kelvin: is there an owner for this?
        - Chris: no
    - 88: (new) chairs to wrap up release dates
        - Kelvin: hoping to get with Chris and post proposal
        - people may post mail stating their view of critical dates
    - new: binary token & xml token types being abstract (Don)
        - stays open
    - new: interop spec uses mustUnderstand=true rather than =1
        - Hal: fixed in draft 3
    - new: multiple recipient email (Hal)
        - Hal: not a separate issue, part of the order of decryption
        - no one commented, so if you want to do it, you're on your own
        - CLOSED
        - Kelvin: should go into issues list for tracking
    - new: complaint with interop example 2
        - Hal: fixed in latest draft
        - CLOSED

> 7. Continue the discussion of the Receipt Token Profile document
>    < http://lists.oasis-open.org/archives/wss/200305/msg00020.html >

- Kelvin: heard silence on this topic during issues list discussion
- Eric: can put presentation together for F2F
- sounds great

> 8. Discussion of key TC milestones

- Kelvin: had hoped to get with Chris prior to call
- should postpone until next call
- people should post strong opinions to list
- Hal: has question on whether we'll need another interop
- we're currently excluding certain token types
- Kelvin: we'll need to impose a date by which all critical issues
  must be raised

> 9. Other business

- Ron: can we hear more about interop?
- what are configurations going to be?
- Hal: expects companies to pair off, and test each client against
  each server
- switch pairings until all combination are made
- [more discussion]
- Eric: sent out a doc last week based on internally-derived tests
- Hal: looked very good
- Chris will talk with Hal about a script

> 10. Adjourn

- Adjourned


Attendance of Voting Members:

  Frank Siebenlist Argonne National Lab
  Irving Reid Baltimore Technologies
  Peter Dapkus BEA
  Hal Lockhart BEA
  Symon Chang CommerceOne
  Thomas DeMartini ContentGuard
  TJ Pannu ContentGuard
  Shawn Sharp Cyclone Commerce
  Ganesh Vaideeswaran Documentum
  John Hughes Entegrity
  Tim Moses Entrust
  Toshihiro Nishimura Fujitsu
  Yutaka Kudo Hitachi
  Jason Rouault HP
  Maryann Hondo IBM
  Kelvin Lawrence IBM
  Anthony Nadalin IBM
  Don Flinn Individual
  Phil Griffin Individual
  Bob Morgan Individual
  Chris Kaler Microsoft
  Prateek Mishra Netegrity
  Frederick Hirsch Nokia
  Senthil Sengodan Nokia
  Charles Knouse Oblix
  Steve Anderson OpenNetwork
  Vipin Samar Oracle
  Jerry Schwarz Oracle
  Eric Gravengaard Reactivity
  Rob Philpott RSA Security
  Peter Rostin RSA Security
  Martijn de Boer SAP
  Pete Wenzel SeeBeyond
  Yassir Elley Sun Microsystems
  Ronald Monzillo Sun Microsystems
  Sirish Vepa Sybase
  Jan Alexander Systinet
  Don Adams TIBCO
  John Weiland US Navy
  Phillip Hallam-Baker VeriSign
Attendance of Observers or Prospective Members:

  Andrew Nash RSA Security
  Jonathan Tourzan Sony

Membership Status Changes:

  Trevor Perrin Individual - Granted voting status after 5/20/2003 call
  Chris Kurt Microsoft - Lost voting status due to inactivity
  Michael Nguyen The IDA of Singapore - Lost voting status due to inactivity


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