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: RE: [wss] Minutes for Telecon, Tuesday 11 March 2003

Added attendance info for:
  - Nataraj Nagaratnam IBM


-----Original Message-----
From: Steve Anderson 
Sent: Thursday, March 13, 2003 3:23 PM
To: OASIS WSSTC (E-mail)
Subject: [wss] Minutes for Telecon, Tuesday 11 March 2003

Minutes for WSSTC Telecon, Tuesday 11 March 2003
Dial in info: +1 877 302 8255  #3578623
Minutes taken by Steve Anderson


    - Minutes from 25 February 2003 meeting accepted (unanimous)
    - We instruct the editors to clarify the language around timestamp
      recipient, and to clarify handling of expiration after interop
    - To push this [discussion of defining a type for tokens] out until
      after interop drafts (one objection)
    - To freeze current drafts (listed below) as basis for interop, and
      only make tweaks as necessary for interop (unanimous)
        - WSS: SOAP Message Security, Draft 11
        - WSS: Username Token Profile, Draft 2
        - WSS: Kerberos Token Profile, Draft 3
        - WSS: X509 Token Profile, Draft 3
        - WSS: SAML Token Profile, Draft 6
        - WSS: XrML Token Profile, Draft 3
        - WSS: XCBF Token Profile, Draft 1
  New (General) Action Items:
    - Editors to clarify the language around timestamp recipient, and to
      clarify handling of expiration
    - Chris will write up scenarios details and send to list

  Issues List Action Items & Status Updates:
    - 69: DEFERRED to post-interop revision
    - 70: DEFERRED to post-interop revision
    - 71: DEFERRED to post-interop revision
    - 72: DEFERRED to post-interop revision
    - 73: DEFERRED to post-interop revision
                             Raw Notes

> Agenda:
> 1. Roll call

- Attendance attached to bottom of these minutes
- Quorum achieved

> 2. Review minutes from previous meeting (2/25/2003)
>    < http://lists.oasis-open.org/archives/wss/
>      200302/msg00067.html >

- [VOTE] unanimous consent, accepted

> 3. Outstanding interop test issues (do we have any?)

- John: new issues 69-72 need to be covered
- Jerry: had sent an issue that hasn't been added
- John: will add
- going thru issues
    - 69: from Peter Dapkus
        - recently joined group
        - didn't see enough in keyIdentifier to implement
        - John: is this an issue that must be resolved for the interop
        - Chris: this hasn't been identified as an interop scenario
        - suggests postponing until after interop
        - editors should respond to Peter's email on the list
        - Ron: aren't keyIdentifiers the preferred reference form for a
        - keyIdentifier text should be moved into profiles, instead of
        - Ron: specific profiles must describe how to use keyIdentifier
        - Chris: thinks we should defer this until we close on the X509
        - for the interop demo, we can fix the cert used on both sides
        - question of how much we are going to bite off in this test
        - the keyIdentifier can be a constant
        - Ron: thought we would want to include a cert, and use 
          keyIdentifer to point to it
        - Chris: what do others think?
        - Martijn: agrees with keeping first demo simple
        - Ron: what are we testing? a validated signature?
        - Martijn: timestamp, encryption, c14n, ...
        - Chris: thinks this will be a big interop step
        - Chris: suggests not putting cert in header, instead, use STR
          with a keyIdentifier
        - ??: suggestion to use ID references
        - Chris: great idea, and we can deal with keyIdentifier in next
        - you only need keyIdentifier if the token isn't in the msg
        - Peter: if we don't use keyIdentifier in the demo, he's fine
          with deferring
        - Ron: didn't think we could avoid using keyIdentifiers, but 
          understanding of them is changing
        - DEFERRED
    - 70: from Eric Gravengaard
        - John: these all look like post-interop issues
        - first part of issue deals with faults
        - second part deals with use of mustUnderstand
        - Chris: don't think we need to worry about mustUnderstand for
          the interop
        - DEFERRED
    - 71: from Ron Monzillo
        - inconsistencies with MUST/SHOULD for token pre-pending
        - John: this could impact interop
        - Ron: thinks this is a high-level question
        - John: for interop, we can agree that this is a MUST, then
          afterwards, debate it as a MUST/SHOULD
        - Ron: what was intent?
        - John: it should be helpful to order in this fashion, but there
          could possibly be reasons an implementation couldn't do it
        - Hal: there's no cryptographic assurance to this
        - John: true
        - proposal: for interop demo, make it a MUST, then have this
          debate afterward
        - Hal: if msg passes thru nodes, each adding tokens properly,
          there's no assurance that someone didn't shuffle them, so
          just want to make sure no one counts on this
        - Hal: agrees with John's suggestion
        - Ron: given Hal's comments, thinks this ought to be a SHOULD,
          since all it is there for is improving performance
        - Peter: seems to complicate interop to say SHOULD vs. MUST
        - John: trying to come to closure, returns to his proposal, and
          is agreeable to Ron's suggestion to make it a SHOULD in the
          spec after interop
        - DEFERRED
    - 72: from Peter Dapkus
        - dependency on namespace, particularly with timestamps
        - John: thinks this is deferrable
        - Peter: as long as interop doesn't use timestamp
        - John: doesn't agree
        - Chris: points out confusion over this being an external 
          dependency, since we define wsu
        - John: URIs can just be used, and we can debate their
          correctness later
        - Jerry: returns to fact that wsu is defined by us
        - Peter: will look at it again
        - moving on to issue with 'expires'
        - seems to introduce risk
        - John: when a recipient gets a msg, it has to deal with clock-
        - cryptographically, we can deal with alterations of the msg
        - if we trust the other party, we can determine if we trust the
        - Hal: exact text is less specific than this discussion suggests
        - John: the context of the timestamp dictates interpretation, and
          in this case, it is WS-Security, which we control
        - Hal: wording is not very clear
        - John: motion to fix recipient and sender wording
        - Ron: what lines?
        - Hal: in section 10, lines 1262 in version 11
        - John: motion is around interpretation of 'expires'
        - <more explanation>
        - Jerry: we should not leave the return of a fault in the case of
          an expiration
        - Ron: disagrees, should be up to policy
        - John: also have to be careful mandating error responses to
          protect against Denial of Service attacks
        - Tony: can to the Security Considerations some text around not
          dictating error responses
        - [MOTION] For purposes of interop testing, we can move on.  We
          instruct the editors to clarify the language around timestamp 
          recipient, and to clarify handling of expiration after interop
        - [VOTE] unanimous
    - missed an issue from Jerry -- becomes #73
        - Jerry: had to do with what tokens are allowed within a token
        - had made a motion to add an embedded reference, but this isn't
        - John: do you see this as an interop issue?
        - Jerry: depends on whether we'll use embedded tokens
        - Chris: that's not planned for interop
        - Ron: but we want a pretty firm schema going into interop
        - Chris: this shouldn't require a schema change
        - Ron: not convinced
        - Chris: expects we'll use an 'any', and have to address it with
        - Ron: can't we define a type for this?
        - Chris: because we want to leave open the definition of other
          token types, that would be problematic
        - John: [MOTION] to push this out after interop drafts
        - Ron: wants us to have a schema with such a fundamental issue
        - suggests a type, called Security Token, and have within it an
        - John: already have this flexibility at the top
        - Ron: but you can't distinguish a token-'any' from any other 
        - Chris: questions need to have a schema that doesn't need
          changes before interop, since interop is supposed to uncover
          needed changes
        - Ron: thinks this is a big hole and we don't seem interested in
          dealing with it
        - concerned that interop will lead to proliferation of 
          implementations, which will make changes less acceptable
        - Chris: looking for a vote on motion
        - Jerry: will we stop discussion on this until after interop?
        - Chris: no, just wants to label this doc set for interop, then
          we can get coding against it
        - [VOTE] one objection, passes

> 4. Discussion of updated specs

- Kelvin: OASIS shut down FTP in anticipation of switch to new system,
  so the docs may remain stale for a while
- Chris: thinks issues 66 & 68 are pending review
- Tony: update on latest doc (draft 11)
    - takes care of open issues, including embedded tokens, and some
      wording clarification for Ron & Frederick
- Chris: can we close 66 & 68?
- Jerry: has editorial issue with embedded text, which says it contains
  a SAML assertion, but the example actually doesn't
- Chris: can add to editorials to change after interop
- Ron: wants to comment on 66, which isn't an interop issue.  Did we
  just close it?
- Chris: no, just deferred
- Ron: concerned with 'post-interop' approach, for instance SAML interop
  can't happen until after this interop
- Chris: true
- Kelvin: agenda includes discussion of scenarios
- Ron: right, but we're eliminating options for that discussion
- Kelvin: nothing is set in stone, and we can come back to these
- Ron: what is correct order of tokens and processed data that uses that
- Chris: intent is to process tokens before needing to use them in 
  processing other message elements
- jumping to agenda item 6

> 6. Discussion of scenarios for interop test

- Kelvin: let's discuss Chris' posted scenarios
- Chris: was proposing a simple set of steps to test the core stuff, then
  add a few variations
- Zahid had sent additional scenarios, which are good, but are more 
  complex than we probably want for the first test
- We can have another interop event with more options
- Martijn: has issue with 2nd scenario, since many systems won't have
  access to passwords, either in cleartext or in hashed form
- Ron: wants to make sure scenarios are something everyone can do
- Tony: not everyone will choose to implement all scenarios, some will
  implement clients vs. servers
- Ron: regarding passwords, doesn't seem like sending them over SSL is
  really adding anything, and that this is the place to do encrypted pwds
- Chris: the interop isn't to justify aspects of spec, it's to flesh out
  basic elements, many of which mirror what is done in other ways now
- Ron: proposes replacing #2 with sending the password encrypted for the
  server, without SSL
- Chris: thinks this is great
- Peter: doesn't think this is useful, because you're just swapping one
  secret for another
- Martijn: suggests adding a timestamp, and a nonce
- Chris: actually, you'd want to encrypt the password hash, rather than
  password itself, but we can work that out
- Jerry: wants more msg detail
- Chris: intends to do that, but only after we agree at highlevel
- Chris: looking for feelings on these 4 (including Ron's suggested
  change to #2)
- Ron: actually this is only 3, with #4 being 'variations', but doesn't
  think we need those variations
- Chris: #4 would be #3 with different c14n and encryption alg
- Ron: do we need different c14n?
- Chris: we need to cover standard & exclusive c14n
- Ron: shouldn't exclusive be preferred?
- Chris: yes, but standard is very prevalent
- <more discussion>
- Chris: we can drop standard c14n, but thinks it will be unfortunate for
  overall interop
- also concerned that if we limit this too much, the demo will be done by
- Hal: suggests we flesh out #4 further on the list
- Chris: agrees
- discussion of un/willingness to participate if all scenarios can't be
- general agreement to further expound on #1, #3 & #4 from Chris' email,
  plus Ron's altered #2
- Jerry: has been waiting to comment on #2, specifically about the 
  response being signed, which should be a separate test
- doesn't want to use SSL at all
- wants a request with no security header, and a response that does have
  a security header
- ??: re-iterated desire not to use SSL, which will only complicate event
- Chris: fine with that

> 5. Do we now have an "interop draft"?

- Chris: thinks we do, do others agree?
- [MOTION] To freeze current drafts as basis for interop, and only make
  tweaks as necessary for interop
- Tim: had an issue with X509 profile, which haven't been addressed
- Chris: thinks they were, in revision ~2 weeks ago
- Peter: still doesn't see usefulness in encrypting username/pwd, but
  doesn't feel strongly about it
- [VOTE] no objections
- [ACTION] Chris will write up scenarios details and send to list
- Jerry: does not want to see documents on web site labeled 'interop
- we've not agreed to that, we've just agreed to use particular drafts for
  this event
- Chris: fine with that

> 7. Discussion of next F2F place and time

- out of time, not discussed

> 8. Other business

- none

> 9. Adjourn

- Adjourned


Attendance of Voting Members:

  Don Adams TIBCO
  Zahid Ahmed Commerce One
  Steve Anderson OpenNetwork
  Lloyd Burch Novell
  Paul Cotton Microsoft
  Venkat Danda IONA Technology
  Peter Dapkus BEA
  Martijn de Boer SAP
  Thomas DeMartini ContentGuard
  Yassir Elley Sun Microsystems
  Don Flinn (individual)
  Eric Gravengaard Reactivity
  Frederick Hirsch Nokia
  Maryann Hondo IBM
  Merlin Hughes Baltimore Technologies
  Chris Kaler Microsoft
  Charles Knouse Oblix
  Yutaka Kudo Hitachi
  Guillermo Lao ContentGuard
  Kelvin Lawrence IBM
  Hal Lockhart BEA
  Ronald Monzillo Sun Microsystems
  Bob Morgan (individual)
  Tim Moses Entrust
  Anthony Nadalin IBM
  Nataraj Nagaratnam IBM
  Toshihiro Nishimura Fujitsu
  TJ Pannu ContentGuard
  Rob Philpott RSA Security
  Hemma Prafullchandra VeriSign
  Ed Reed Novell
  Irving Reid Baltimore Technologies
  Peter Rostin RSA Security
  Jason Rouault HP
  Rich Salz Data Power
  Vipin Samar Oracle
  Jerry Schwarz Oracle
  Senthil Sengodan Nokia
  Shawn Sharp Cyclone Commerce
  John Shewchuk Microsoft
  Frank Seibenlist Argonne National Lab
  Gene Thurston AmberPoint
  Ganesh Vaideeswaran Documentum
  Sirish Vepa Sybase
  Sam Wei Documentum
  John Weiland Navy
Attendance of Observers or Prospective Members:

  John Hughes Entegrity
  ?? ?? Perficient (expecting email for identification)

Membership Status Changes:

  Toufic Boubez Layer 7 -- Lost voting status due to inactivity
  Mark Nobles LMI -- Lost voting status due to inactivity
  Rajesh Raman BEA Systems -- Lost voting status due to inactivity


To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

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