SSTC telecon minutes 2004-09-14

minutes for OASIS SSTC conference call Tuesday 2004-09-14
minute taker:  RL "Bob" Morgan

Summary:

   Votes:

   * accept text changes in items a, b, d, e, f as noted below
   * accept text change re confirming entity in SubjectConfirmation
       (partial item c)
   * accept text change re one-time semantic enforcement for artifact
   * accept text change re EncryptedID qualifier attributes

   Extended discussion:

   * IssuedTo element:  no consensus for including it yet
   * requiring error responses:  strict vs loose debate

   New action items:

   * none

---

Raw notes:

0.  Attendance taken, quorum achieved

1.  Aug 31 con call minutes accepted unanimously

2.  revised timeline posted to list

3.  voting on changes proposed as a result of comments on CD

   (a)  New text on SessionIndex
http://lists.oasis-open.org/archives/security-services/200409/msg00015.html
     unanimously accepted

   (b)  Proposed text for Attribute Value clarification
http://lists.oasis-open.org/archives/security-services/200409/msg00031.html
     unanimously accepted

   (c)  Proposed text for adding ID of confirming entity
http://lists.oasis-open.org/archives/security-services/200409/msg00032.html
   discussion:
     Scott:  original proposal (from Gary Ellison)
       was to add optional sequence of
         "issued-to" elements, still a good idea
         represents last of entities involved in transaction
         this is "presenter" of request
     Irving:  OK to put in, but should be discouraged unless well-profiled
     Scott:  yes, shouldn't modify standard SSO profiles to use it
     Ron:  who is presenter?  is it clear who is whom?
       these are not necessarily all distinct parties, right?
     Scott:  can be distinct, or not
     Ron:  now we're separating issued-to from confirmation, right?
     JohnK:  yes, that was Gary's proposal
     (more discussion ...)
     Ron:  have to say what it means when it's omitted, to be clear
     Scott:  yes, omission should mean "don't know"
     JohnK:  sounds like we need respun text combining both proposals
     Scott:  will do
   Prateek:  defer until then

   (d)  text to clarify lack of "direction" in use of NameQualifier
http://lists.oasis-open.org/archives/security-services/200409/msg00033.html
     unanimously accepted

   (e)  text for replacement/enhancement of Recipient
http://lists.oasis-open.org/archives/security-services/200409/msg00034.html
     Scott:  at Jeff's suggestion, added to it rather than removing it
       propose to rename it also, since Recipient is already used ...
       based on WS-addressing, propose "Destination", implying location
         could use WS-addr directly if/when it's standardized
           in WS-flavored profiles
     unanimously accepted

   (f)  proposed new X.500/LDAP attribute profile text
http://lists.oasis-open.org/archives/security-services/200409/msg00035.html
      Eve:  name change from LDAP to X.500 will affect several docs
      RLBob:  URN changed, text name of profile didn't
     unanimously accepted

4.  more discussion of comments

  * message today from Quadrasis re glossary terms
    Scott:  hoping to get rid of "SSO assertion" term
      will go through docs to make sure it's expunged
    Jeff:  OK, should remove it then
      can revise glossary this week
    Prateek:  OK, can have it ready for vote next week

  * one-time artifact enforcement
    Scott:  Conor proposed better language in his message
    Conor:  point is to clarify how it can be done
    moved to include language from referenced message 
(200409/msg00046.html)
    unanimously accepted

  * Conformance requirements - SSL/TLS issues
    Prateek to do more research on why original language is there
    Scott:  text in bindings now in conformance
    Prateek:  yes

  * Scott:  change proposed still needs to be accepted:
http://lists.oasis-open.org/archives/security-services/200409/msg00030.html
    qualifier attributes on EncryptedID element don't make sense
    question about need to identify source of encryption
    Greg:  don't see the need, handled elsewhere in message if needed
      when Encrypted nameid is decrypted, has all original qualifiers?
    Scott:  yes
    unanimously accepted

AIs:

  #0195: Publish glossary text for SessionAuthority, SessionParticipant
  JohnK will do

  #0160: Separate Privacy concerns language from Element/Attribute
    descriptions
   remains open

  #0158: Propose changes to definition of Federation in glossary
   remains open

  #0123: Obtain MIME type registration for HTTP lookup of SAML
   JeffH:  comments from reviewers re magic numbers,
     and XML awareness of MIME processor
     should be ready to go to IESG

Scott:  text sent just now re IssuedTo/Confirming Entity:
http://lists.oasis-open.org/archives/security-services/200409/msg00051.html
   Ron:  seems open-ended, a placeholder for future real semantics
   Scott:  mostly for auditing
   Rob:  so, shouldn't this be done via extension by those defining it?
   Scott:  but it's hard to extend assertion, is there extensions element?
     no, there's not, maybe should do one
   Ron:  assumes authentication to get name that's put in
     since it will be relied on
   Scott:  only other extension points are Conditions and Advice
     those don't seem right for this
   JohnK:  does it have to be "profiled out" in existing profiles
     no different than other optional things whose use isn't specified
       in those profiles
   RLBob:  much prefer to be done as extension, rather than putting
     poorly-defined items into core spec
   JohnK:  does have defined use, but not in existing profiles
   Rob:  can't we add optional element in 2.1?
   Scott:  would break conforming 2.0 implementations
   Scott:  now seems like this can be in Advice or Condition
     so wouldn't need any other extension point
     profile can say that something must be in Advice
   RLBob:  Condition is meant to be "must understand"
     where Advice is "can ignore"
     so can a profile say that an Advice element must be understood?
   JohnK:  argue that entities involved in assertion-handling
     should be able to be represented in the assertion
   RLBob:  argue that entities are players in some protocol
     and should be represented in that protocol's messages
   Rob:  maybe change Advice so profile can make something mandatory?
   (more discussion ...)
   RLBob:  still a requirement for a new extension point?
   Scott:  doesn't seem like it
   Scott:  so what about original confirming entity proposal
     in SubjectConfirmation?
   Prateek:  seems like people may not understand it still?
   Ron:  this has real use case, solves problem IssuedTo
     was originally proposed for
   Scott:  move to accept text in
http://lists.oasis-open.org/archives/security-services/200409/msg00032.html
   unanimously accepted

item:
   Jeff:  Liberty offering to host SAML 2.0 interop event in November
   Rob:  is that just physical logistics, or test case prep etc?
   Jeff:  could be both
   Prateek:  test cases/scenarios should be in SSTC
   (more discussion of interop ...)

Rob:  message to list about errors and conformance:
http://lists.oasis-open.org/archives/security-services/200409/msg00052.html
   question is about how to respond to message that is schema-valid
     but doesn't conform to spec text, eg UTCDate format
   Rob's opinion is that this is error
     some other opinions that it is valid but should get no response
     spec should mandate error response
   Irving:  shouldn't violate "liberal in what you accept" principle
     ie shouldn't tell RP it has to reject message it can handle
   Scott:  seems like point is not to use "success" to mean failure
     rather to always use real error response
   (more discussion of this issue ...)

---

Attendance of Voting Members  (supplied by Steve Anderson)

   Conor P. Cahill AOL, Inc.
   Rick Randall Booz Allen Hamilton
   Tim Alsop CyberSafe
   Paul Madsen Entrust
   Carolina Canales-Valenzuela Ericsson
   Irving Reid Hewlett-Packard Company
   Paula Austel IBM
   Maryann Hondo IBM
   Michael McIntosh IBM
   Anthony Nadalin IBM
   Nick Ragouzis Individual
   Scott Cantor Internet2
   Bob Morgan Internet2
   Prateek Mishra Netegrity
   Forest Yin Netegrity
   Peter Davis Neustar
   Frederick Hirsch Nokia
   John Kemp Nokia
   Cameron Morris Novell
   Scott Kiester Novell
   Charles Knouse Oblix
   Steve Anderson OpenNetwork
   Ari Kermaier Oracle
   Vamsi Motukuru Oracle
   Darren Platt Ping Identity
   Jim Lien RSA Security
   John Linn RSA Security
   Rob Philpott RSA Security
   Dipak Chopra SAP
   Jahan Moreh Sigaba
   Bhavna Bhatnagar Sun Microsystems
   Jeff Hodges Sun Microsystems
   Eve Maler Sun Microsystems
   Ron Monzillo Sun Microsystems
   Greg Whitehead Trustgenix

Attendance of Prospective Members or Observers

   Abbie Barbir Nortel
   Andy Moir OASIS

Membership Status Changes

   Adam Dong Sun Microsystems - Requested membership on 9/9/2004
   Abbie Barbir Nortel - Granted voting status after 9/14/2004 call
   James Vanderbeek Vodafone - Lost voting status after 9/14/2004 call