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 3 December 2002

Minutes for WSSTC Telecon, Tuesday 3 December 2002
Dial in info: +1 865 524 4287 #248770.
Minutes taken by Steve Anderson
    - Minutes from 19 November 2002 meeting accepted (unanimous)
  New (General) Action Items:
    - Steve to post list of all responses (and lack thereof)
  Issues List Action Items & Status Updates:
    - 14: issue closed
    - 15: issue closed
    - 19
        - Tony to reduce core coverage of username/password
          token to most minimal amount
        - PhilG to produce draft of username/password token
          profile doc, with Tony's assistance
    - 20: issue closed
    - 23: issue closed
    - 24: issue closed
    - 25: issue postponed
    - 26
        - Tony to get with Ron for final wording
    - 39: issue closed
    - 44: issue closed
    - 45: issue closed
                             Raw Notes
> Agenda:
> 1. Roll call
- Attendance attached to bottom of these minutes
- Quorum achieved
> 2. Review minutes from previous meeting (11/19)
>    < http://lists.oasis-open.org/archives/wss/200211/msg00184.html <http://lists.oasis-open.org/archives/wss/200211/msg00184.html>  >
- [VOTE] unanimous consent, accepted
> 3. Actions/Issues list
- JohnS: posted updated issues list
  < http://lists.oasis-open.org/archives/wss/200212/msg00011.html <http://lists.oasis-open.org/archives/wss/200212/msg00011.html>  >
    - 14: Previously marked pending, Ron was to validate
        - Ron: not sure how he was to validate, since it was his issue
        - not sure if anyone else reviewed it
        - Ron directs folks to lines 297-310 of profile
        - no objections to this
        - CLOSED
    - 15: has been clarified in draft -05, lines 161-164
        - actually changed in prior version (see ver -02 or -03)
        - no objections to changes
        - PhilG: has tangential comments
        - core doc confusing, particularly with use of term "role"
        - would like "soap role"
        - Tony: has been clarified
        - CLOSED
    - 19: was marked pending
        - Ron: doesn't believe issue is closed
        - text added to section 3.1
        - wants username/password described in providing a key
        - PhilG: was puzzled reading comments on this, stating that
          username/password is not tied to a key
        - Ron: can use username token to name a password
        - ChrisK: can we leave this as pending and have Ron get with
          Tony to clarify text?
        - Ron: yes
        - Tim: are we or are we not describing security protocols?
        - line 468 indicates we are, but section 1.1 says we are not
        - Ron: how can username express the scope, such as RACF vs. 
          web sign-on, etc?
        - could be concatenated in username
        - RLBob: SAML has structure to name identifier
        - Tim: looking at the schema, password is expressed via an 
          'any', so couldn't other items be added where useful, such
          as scoping the username?
        - JohnS: schema is not normative, the document is
        - discussion on normative aspects of schema and the document
        - XMLSchema has limitations that must be addressed by document
        - PhilG: why not declare the password as optional, and leave
          the 'any' for future use
        - JohnS: tried this approach and found technical limitations
          with various tools
        - Ron: seems that this is very profile-specific, and would 
          prefer normative additions in the core spec remain profile-
        - JohnS: want a common authentication mechanism supported by
          all implementations
        - Ron: can make certain profiles mandatory
        - Zahid: doesn't this belong in a conformance spec?
        - Tony: yes, but you need normative base for the conformance
        - Ron: not sure he likes sending the password in a SOAP header
        - Tony: winds up being no worse than HTTP today
        - discussion of sending passwords through intermediaries, 
          employing digests and XML Encryption
        - common use case of web service needing to access back end DB
          on behalf of the web service client, needing the client's 
        - Hal: contends that the password becomes more of an attribute
        - Ron: definitely needs to be more detail on the use of these
        - Don: two separate issues at work here
            - what are the semantics
            - profile vs. core
        - PhilG: concerning profile vs. core, the options appear to be:
            - completely extract username token from core doc
            - identify it in the core doc and further define it in 
              the profile (like the binary token is treated)
        - prefers the latter choice
        - Kelvin: wants the reader of the spec to get some clarity 
          without having to read additional profile docs
        - Kelvin: notes that we voted at the F2F not to do this
        - Tony: are there strong objections to keeping some minimal
          amount of coverage in the core and the rest in a binding?
        - none
        - [ACTION] Tony to reduce core coverage of username/password
          token to most minimal amount
        - Tony needs help on profile doc
        - PhilG offers to help
        - [ACTION] PhilG to produce draft of username/password token
          profile doc, with Tony's assistance
    - 20: Tony updated core doc, awaiting approval from issue owner
        - Ron: was his, seems fine
        - CLOSED
    - 22: pending
        - Ron: was his, not sure why it's still pending
        - gave Tony text yesterday, which he put in doc, but can't 
          interpret change bars yet
        - will keep pending
        - Tony will post doc without changebars today
    - 23
        - Ron: should be closed
        - CLOSED
    - 24
        - Ron: should be closed
        - CLOSED
    - 25
        - Ron: we never resolved this issue
        - Tony: in the current incarnatino, a signature element 
          occurring outside of the header cannot be referenced
        - Ron: so the question is answered, but the issue of the value
          of being able to do this remain
        - Ron: believes that such signatures could technically be
          referenced, but the question is how could you secure those 
        - Ron: will require some more thought and discussion
        - Tony: is this something we want to tackle? can we do it
          outside of core?
        - Ron: agrees that it could be addressed outside core
        - POSTPONED     
    - 26: editors have updated this in draft -03 or -04
        - no objections
        - Tim: from a complete conformance perspective, more detail
          will be required
        - Ron: this was his reason for raising this
        - Tony: you must be able to recognize all binary tokens, but
          not necessarily process all forms of binary tokens
        - PhilG: differentiation on recognizing the wrapper around the
          token vs. the internal token itself, and not blow up
        - Tony: so would such a clarification be acceptable?
        - yes
        - must be able to at least respond with an error code when an
          unacceptable binary token is received
        - still open
        - [ACTION] Tony will get with Ron for final wording
    - 28
        - Ron: would like to leave this open
    - 29
        - Prateek: published a note describing use case
        - hasn't received much in the way of comments
        - would like to leave pending, and if there are no additional
          comments by next week, we can close it
        - what does 'close it' mean?
        - close it and do nothing
    - 30
        - still open
    - 31
        - Kelvin: went to OASIS to ask about their naming policy
        - they don't have a solution for URL space
        - ChrisK: is everyone comfortable keeping it as is for now?
        - RLBob: why is URN not sufficient
        - ChrisK: trend lately is for Schema URIs to actually be
          referenceable, in order to get the schema
        - still open
    - 36: Tony was to address this in latest rev
        - hasn't been addressed yet
        - leave pending
    - 38
        - Don: Konstantin will post to list shortly
        - Kelvin: emphasize that this has been on Konstatin's plate 
          for several calls
        - still pending
    - 39
        - Ron: believes that it has been fixed, but hasn't been able
          to verify
        - reviewed on call
        - CLOSED
    - 42: has been clarified in current draft
        - needs review and confirmation, particularly by Konstantin
        - still pending
    - 44
        - Don: thought we had a long discussion of this and everyone
          was comfortable with it
        - Ron: changes begin with line 300 in the SAML profile
        - CLOSED
    - 45: Tony has added definitions for these terms
        - Don: looks fine
        - no objections to these changes
        - CLOSED
    - 46
        - believe issue was raised by David Orchard
        - Ed Reed also had action to communicate with D Orchard on this
        - Ron: wasn't this related to QoP issue?
        - believe so
        - Tony: this QoP issue does not have bearing on core
        - Prateek: this has little to do with SOAP and WSDL, and more
          to do with the use of WS-Sec
        - Ron: we do need to identify what the core parameters that 
          must be negotiated
        - discussion terminated due to time
        - will be taken up on list and at F2F
        - still open
> 4. Update on face-to-face logistics
- [ACTION] Steve to post list of all responses (and lack thereof)
- concern over potential lack of quorum
- options
    - F2F becomes focus group, and decisions can be voted on later
    - ask members to step down from voting status
    - provide dial-in
    - can also use Leave of Absence, rather than completely stepping
- ChrisK: concerned that issue owners will not be in attendance, and
  we'll rehash the discussions later
> 5. Any other business
- none
> 6. Adjourn
- Adjourned

Attendance of Voting Members:
  Don Adams TIBCO
  Zahid Ahmed Commerce One
  Jan Alexander Systinet
  Steve Anderson OpenNetwork
  Toufic Boubez Layer 7
  Paul Cotton Microsoft
  William Cox BEA
  Venkat Danda IONA Technology
  Martijn de Boer SAP
  Thomas DeMartini ContentGuard
  Don Flinn Quadrasis
  Peter Furniss Choreology
  Simon Godik Overxeer
  Eric Gravengaard Reactivity
  Sam Greenblatt Computer Associates
  Phil Griffin Griffin Consulting
  Jeff Hodges Sun Microsystems
  Maryann Hondo IBM
  Merlin Hughes Baltimore Technologies
  Chris Kaler Microsoft
  Charles Knouse Oblix
  Yutaka Kudo Hitachi
  Guillermo Lao ContentGuard
  Kelvin Lawrence IBM
  Hal Lockhart Entegrity Solutions
  Monica Martin Drake Certivo, Inc.
  Prateek Mishra Netegrity
  Ronald Monzillo Sun Microsystems
  Bob Morgan (individual)
  Ron Moritz Computer Associates
  Tim Moses Entrust
  Joel Munter Intel
  Anthony Nadalin IBM
  Nataraj Nagaratnam IBM
  Andrew Nash RSA Security
  Toshihiro Nishimura Fujitsu
  Mark Nobles LMI
  Rob Philpott RSA Security
  William Pope Choreology
  Hemma Prafullchandra Verisign
  Ed Reed Novell
  Irving Reid Baltimore Technologies
  Peter Rostin RSA Security
  Vipin Samar Oracle
  Jerry Schwarz Oracle
  Senthil Sengodan Nokia
  Shawn Sharp Cyclone Commerce
  John Shewchuk Microsoft
  Frank Siebenlist Argonne National Lab
  Andre Srinivasan E2open
  Andrew Sweet Perficient
  Gene Thurston AmberPoint
  Steve Trythall Sonic Software
  Ganesh Vaideeswaran Documentum
  Sam Wei Documentum
  John Weiland Navy
  Pete Wenzel SeeBeyond

Attendance of Observers or Prospective Members:
  Frederick Hirsch Nokia
  Lloyd Burch Novell

Membership Status Changes:
  Lloyd Burch Novell - Requested membership 11/25/2002
  Hank Simon Lockheed Martin - Granted voting status after call
  Frederick Hirsch Nokia - Granted voting status after call
  Geff Hanoian Overxeer - 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