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] | [Elist Home]

Subject: [wss] Minutes for Telecon, Tuesday 25 February 2003

Minutes for WSSTC Telecon, Tuesday 25 February 2003
Dial in info: +1 (405) 244-5555  #6921
Minutes taken by Steve Anderson


    - Minutes from 11 February 2003 meeting accepted (unanimous)
    - To redefine the transform for Signing Tokens (see section 8.3 in
      draft 10 of the core) such that it only defines how a referenced
      (by ds:Reference attributes or by XPath node-set) 
      SecurityTokenReference is dereferenced to get the SecurityToken to
      be digested. The STR-transform will no longer be used to directly
      reference a SecurityToken by including a STR within the transform.
    - Add subsection to section 7 to define the case where the a security
      token can be a subelement of a STR (unanimous)
  New (General) Action Items:
    - Editors to incorporate change voted on for Signing Token transform

  Issues List Action Items & Status Updates:
    - 60: CLOSED
    - 61: CLOSED
    - 66: PENDING
    - 68: PENDING
                             Raw Notes

> Agenda:
> 1. Roll call

- Attendance attached to bottom of these minutes
- Quorum achieved

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

- [VOTE] unanimous consent, accepted

> 3. Kavi migration update

- general warning of upcoming go-live date: 3/13
- everyone should get their own userid/password before that
- everyone should verify their expected TC membership status
- send email to Steve Anderson for inconsistencies for WSSTC

> 4. Issues list

- Will take pass through pending items
    - 60 
        - Thomas: there were a few things overlooked, which he mailed
          Tony about
        - Tony: has updated next draft with those changes
        - Ron: requested copy of Thomas' msg
        - CLOSED
    - 61
        - Frederick was to review
        - Frederick will be late to call today, will pick up after he
    - 66
        - Action was for people to go off and review the transform
        - Tony: this isn't the latest draft, and there is one nit
          from Frederick
        - Hal: what is the number of latest draft?
        - Tony: 10
        - Kelvin: should be on list, in an email from Sunday night,
          but it's not yet linked on the web site
        - Ron: has had questions from within Sun about not using standard
          transforms like XPath
        - Chris: in some cases XPath may be difficult for referencing
        - Ron: there are two halves to this, a dereferencing transform and
          a data reference for security tokens
        - Tony: what is the advantage to going the XPath route?
        - Ron: (described an interoperability issue)
        - Ron: have to be able to data-reference anything, including
          a security token, which we can with XPath
            - have to reference what you want to sign
            - could be a STR, using normal XPath form
        - Chris: but you may not be able to
        - suppose you have a header with 6 SAML tokens
            - you could reference by index, assuming no one reorders them
            - can't reasonably reference them by identifier with XPath
        - Ron: boils down to the fact that we have this powerful XPath
          that can reference anything anywhere, but we are building
          another one
        - Chris: extending it to reference anything anywhere becomes more
          complex than using a specific, simple, well-known transform
          for our specific referencing need
        - Chris: XPath has a number of scenarios it works well for, such
          as when an XML ID is available. We're just calling out
        - Jerry: re-phrasing Ron's interoperability concern, thinks it
          comes down to inventing new transforms, and the burden it 
          places on digit signature implementations
        - believes that right approach is to make tokens uniform, and if
          necessary, add a wrapper
        - John: tokens will be non-uniform, as people define all kinds
          of token types, and we want to be able to support them
        - Tony: STRs are wrappers, so not sure why there is belief that 
          it is not
        - (discussion of STR as wrapper)
        - Paul: clarifying where we're at in this call
        - Ron: doesn't object to the transform Chris developed, believes
          that it solves one problem well, and wants to understand how
          it solves a second problem
        - Tony: one alternative is to in-line the token in a STR, 
          internally referencing a token
        - Ron: doesn't that imply that you will need to reference this
          STR from another STR
        - do you need another transform for this?
        - Chris: the STR would have an ID, and a simple transform that
          looks for the STR's ID could be developed
        - Ron: thinks we still need a dereferencing token so that STRs
          can be pointed for purposes of signing the STR
        - Frederick: asks for summary of what changed
        - Chris: 
            - we can simplify the transform in the doc to say "don't
              sign the STR, but sign what it references"
        - [MOTION] To redefine the transform for Signing Tokens (see
          section 8.3 in draft 10 of the core) such that it only defines
          how a referenced (by ds:Reference attributes or by XPath 
          node-set) SecurityTokenReference is dereferenced to get the
          SecurityToken to be digested. The STR-transform will no longer
          be used to directly reference a SecurityToken by including a
          STR within the transform.
        - [VOTE] no objection
        - [ACTION] Editors to incorporate the STR change
        - Tony: doesn't see why we can't make it simpler by in-lining the
        - Ron: would there be a transform?
        - Tony: no
        - Ron: doesn't see why it's necessary
        - Jerry: it removes a level of indirection
        - Ron: thinks this is just a wrapper, and you should just call it
        - Jerry: [MOTION] to add to section 7 the ability to add a 
          security token as a child of a STR
        - Ron: we don't have a type for security token
        - Chris: we already have something to reference in a STR
        - Jerry: the sub-element of the STR could be anything that could
          have been found in the <Security> header, since there is no
          security token type
        - Ron: does anyone have a use today where they're directly
          including a security token?
        - Tony: not today, but he's tracking performance issues and this
          would help greatly
        - Ron: assuming that there is a type for security tokens (which
          we don't) and that type exposed an ID, would this motion be
        - Jerry: wouldn't be opposed to that
        - Hal: we had this argument before, and we wanted to associate
          attributes to the token, and unless you want to add that to
          the token type, you still need the reference
        - further, values for such attributes may differ by use, even for
          the same token
        - Ron: if we are literally including a token within a wrapper, why
          not just create a token type, and if we do that, what is the
          value of having the STR mechanism?
        - Hal: thinks you need to pointer-type reference even with the 
        - Ron: thinks that works fine if there can be an expectation that
          each token exposes a consistent exterior, which the wrapper can
        - Ron: getting back to Jerry's motion, he doesn't object to
          placing token literally within a STR, but he was questioning 
          the need for non-internal references, given the wrapping
          ability being proposed, but ready to move on
        - Hal: concerned about semantic confusion with STRs being used
          in these two different ways
        - (more discussion)
        - [MOTION - restated] Add subsection to section 7 to define the 
          case where the a security token can be a subelement of a STR
        - [VOTE] no objection
        - PENDING
    - 61 (Frederick on call now)
        - Frederick: wording in doc is fine
        - Thomas has made other wording issues, which Frederick can
        - CLOSED
    - 68
        - summary of change was to clarify that there is no requirement
          for servers to maintain access to cleartext passwords
        - "shared secret" is the more appropriate term, rather than 
        - hashed values of original passwords could be used
        - Jerry: is there a uniform way to express which shared secret 
          to use
        - Chris: no uniform way, but could define QName values for this
        - PENDING

> 5. Review of updated specs 

- Chris: if there are issues (which block interop), send them to the list

> 6. Do we have an "interop draft" - vote 

- Chris: we still have to develop scenarios (which he owes to the list)
  for an interop event
- seems that the pending issues do not block an interop event
- Ron: are we changing the structure of an STR?
- Chris: we wouldn't likely involve that in this event
- any objections to current version being used as base for an interop
- Hal: any ambiguities can be addressed in the event
- Do we want to address 66 & 68 first?
- Ron: wants to get schema stabilized
- [MOTION] Version 10 of current version, with issues 66 and 68
  incorporated, and with a matching schema, will be used for an interop
- Ron: thought we would have use cases or a script before making such a
- Hemma: thinks that in order to make progress, must start with minimal,
  like username/password
- Hal: thinks there is no urgency to decide on this today
- we can proceed to the interop script
- Prateek: supports Hal's comment
- Tony: concerned at lack of traction
- Ron: thinks starting code requires notion of scenarios
- Chris: will do scenarios in next 24 hours, and Version 11 will be out
- Tony: how many scenarios are we looking at?
- Chris: just a few, like username/password, a small X.509 case, maybe an
  encryption case
- intent is to stir discussion on list and possibly address this desire
  through mail

> 7. Discussion of next F2F place and time

- Chris: given previous discussion, seems premature to discuss this
- Hal: does this imply slipping past Q1?
- Chris: would say yes
- Hopes people are coding to v10, to get a head start on things
- Query for who thinks they'd participate
   - VeriSign
   - MS
   - IBM
   - BEA
   - RSA might
   - Sun will depend on timing
   - caveat echoed by Oracle, Novell, RSA
   - Ron: Sun would prefer not to participate unless they could address
     all scenarios

> 8. Other business

- none

> 9. Adjourn

- Adjourned


Attendance of Voting Members:

  Voting Members  
  First Last Company
  Don Adams TIBCO
  Zahid Ahmed Commerce One
  Steve Anderson OpenNetwork
  Paul Cotton Microsoft
  William Cox BEA
  Peter Dapkus BEA
  Martijn de Boer SAP
  Thomas DeMartini ContentGuard
  Yassir Elley Sun Microsystems
  Eric Gravengaard Reactivity
  Phil Griffin Griffin Consulting
  Frederick Hirsch Nokia
  Jeff Hodges Sun Microsystems
  Chris Kaler Microsoft
  Takashi Kojo NEC
  Yutaka Kudo Hitachi
  Guillermo Lao ContentGuard
  Kelvin Lawrence IBM
  Hal Lockhart BEA
  Prateek Mishra Netegrity
  Ronald Monzillo Sun Microsystems
  Tim Moses Entrust
  Anthony Nadalin IBM
  Nataraj Nagaratnam IBM
  Andrew Nash RSA Security
  Toshihiro Nishimura Fujitsu
  Rob Philpott RSA Security
  Hemma Prafullchandra VeriSign
  Ed Reed Novell
  Irving Reid Baltimore Technologies
  Peter Rostin RSA Security
  Rich Salz Data Power
  Vipin Samar Oracle
  Jerry Schwarz Oracle
  Senthil Sengodan Nokia
  John Shewchuk Microsoft
  Frank Seibenlist Argonne National Lab
  Steve Trythall Sonic Software
  Sam Wei Documentum
  John Weiland Navy
  Pete Wenzel SeeBeyond
Attendance of Observers or Prospective Members:

  TJ Pannu ContentGuard
  John Hughes Entegrity
  Don Flinn 
  Monica Martin Drake Certivo, Inc.

Membership Status Changes:

  Michael Nguyen Infocomm Dev Authority of Singapore - Requested membership 2/21/2003
  John Hughes Entegrity - Requested membership 2/24/2003
  TJ Pannu ContentGuard - Granted voting status after 2/25/2003 call
  Erick Herring Digital Evolution - Lost voting status due to inactivity
  Ron Moritz Computer Associates - Lost voting status due to inactivity
  Rob Weltman Netscape/AOL - Lost voting status due to inactivity


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

Powered by eList eXpress LLC