Minutes for Telecon, Tuesday 13 May 2003

Minutes for SSTC Telecon, Tuesday 13 May 2003
Dial in info: +1 865 673 3239 #238-3466
Minutes taken by Steve Anderson

======================================================================
                              Summary
======================================================================

  Votes:
  
    - Minutes from 6 May 2003 call accepted
    - Change IDReference type to xsd:NCName
    - remove ID and IDReference types; transition identifier text from
      section 2.2.1 to section 1, with appropriate edits; remove all 
      other references to those types
    - Add the following text to section 2.3.2.1.4:
      "Issuing authority SHOULD NOT include more than one DoNotCache 
      condition element in an assertion " and "Relying parties MUST 
      interpret multiple DoNotCache elements as equivalent to one"
    - add the following text to section 2.3.2.1.4
      "for the purposes of determining the validity of the conditions 
      element, the DoNotCache condition is considered to always be 
      valid"
    - change authN method description from element to attribute
  
  Previous Action Items Still Open:
  
    - #0004 Propose WSDL for Metadata
    - #0013 Request use of WS-Trust for CC proposal
    - #0034 Correct schema use of xsd:ID and xsd:IDREF
    - #0040 Editorial comments on SAML 1.1 document set

  New Action Items:
  
    - Scott to provide exact changes for ID type resolution
    - Rob to make DoNotCache updates in docs
    - Jahan to add authN method attribute fix to errata
    - Rob to make authN method attribute fix in docs
    
======================================================================
                             Raw Notes
======================================================================

> 
> Agenda:
> 
> 1. Roll call
>

- Attendance attached to bottom of these minutes
- Quorum achieved

> 
> 2. Accept minutes from previous meeting, 6 May
>    < http://lists.oasis-open.org/archives/security-services/
>      200305/msg00091.html >
>

- [VOTE] unanimous consent, accepted

> 
> 3. Review of time-line and next steps
>    < http://lists.oasis-open.org/archives/security-services/
>      200304/msg00133.html >
>

- Rob: Suggests we move this to end of today's call

> 
> 4. Open Actions
>
>    #0004 Propose WSDL for Metadata
>    Prateek Mishra
> 

- Prateek: connected to Metadata proposal
- remains open until time to review that proposal

>
>    #0013 Request use of WS-Trust for CC proposal
>    Maryann Hondo
>

- Rob: no change in status
- Hal: spoke with Maryann
    - most likely scenario is that they'll allow us to use their text
    - problem has been getting all the authors together for consent

>
>    #0033 Create differences between SAML 1.0 and 1.1 document
>    Prateek Mishra
>    < http://www.oasis-open.org/archives/security-services/
>      200305/msg00093.html >
>

- Prateek: published last week, received several comments, will
  revise in next day or so
- CLOSED

>
>    #0034 Correct schema use of xsd:ID and xsd:IDREF
>    Eve Maler
>    < http://www.oasis-open.org/archives/security-services/
>      200305/msg00070.html >
>    < http://www.oasis-open.org/archives/security-services/
>      200305/msg00084.html >
>

- Scott: IDREF is used to point to locations within doc, so this
  cannot be used
- Prateek: it's an error in our schema, and we can't wiggle out of it
- question is "what is the remedy"
- Scott describes two choices proposed: 
    - NCName - same semantics without the restrictions of IDREF
    - URI - but wasn't clear how to express that, due to lack of
      processing rules
- there could be cases where URIs could be used, with fragments 
  pointing to an ID value, but we previously eliminated that option
- for our current common cases, we'd have to invent our own URI
  mechanism
- Prateek: do we lose anything going to NCName?
- Scott: sort of lose the surface impression the reader would have that
  this is supposed to be an ID pointing somewhere
- maybe could wait until 2.0, and refine our use cases
- Prateek: sounds like there's a technical problem here in the XML
  Schema space, because there isn't a question of our intent
- [MOTION] Change IDReference type to xsd:NCName
- Rob: this is a schema change and a change in text
- can someone send exact text?
- Scott volunteers, will send to Rob, and Rob will incorporate
- [VOTE] no objections, passes
- [ACTION] Scott to provide exact changes for ID type resolution
- Prateek: Scott had a second issue here, in pragmatics
- Scott: hasn't had any feedback about other parsers
- knows one of the Xerces parsers is broken
- speaking for Eve (who he spoke with and had agreement) neither see
  much value in what we're doing currently
- informative what to go about this is to find out how many parsers
  have the issue, but that's hard to verify
- has somewhat of a commitment from Xerces team to fix it, but not sure
  when
- Irving: has philosophical issue with deriving type, but not for any
  present use
- Prateek: on contrary, it is placeholder for what we might do with it
  later, to avoid traumatic change
- Irving: but it's speculative
- Prateek: what would happen in section 2.2.1
- Scott: we'd probably leave it or transfer it somewhere else
- Prateek: that's one of the values in keeping this indirection, having
  the explanation all in one place
- Scott: proposal would be to remove the types and change all
  references to it to refer to xsd:ID
- discussion about WS-Security, which uses this, but is phasing it out
- Rob: given the nature of this change, this seems like a fairly
  important, normative change that may need some more review
- we'll need to decide whether to drop this into the current last call
  or to restart a new last call
- Scott: doesn't think this is that substantive
- Irving: the semantics don't change
- Scott: we'll just need to be careful where we make the changes
- [MOTION] several parts
    - removal of ID and IDReference types
    - transitioning of identifier text from section 2.2.1 to section 1,
      with appropriate edits
    - remove all other references to those types
- [VOTE] not objections
- pending Scott's changes

> 
>    #0039  Issues with DoNotCacheCondition
>    Prateek Mishra
> 
>    (a) do we care about cardinality?
>    < http://www.oasis-open.org/archives/security-services/
>      200305/msg00090.html >
> 
<    (b) Explain when DoNotCacheCondition is valid
>    - line [468]
>      "MUST not" should be "MUST NOT" ?
>    - line [553]
>      "MUST not" should be "MUST NOT" ?
>    - about <DoNotCacheCondition> element
>      The processing rules of the sub-elements and attributes of a
>      <Conditions> element are described at line 485-492.
>      To make the relying party possible to follow this rules, each
>      <Condition> element (extension of ConditionAbstractType) should have
>      a clear definition of when it evaluates to Valid.
>      Current description in 2.3.2.1.4 mentions nothing about its validity.
>
>      # I wonder if it is suitable to define <DoNotCacheCondition> as a
>      # sub-element of a <Conditions>. (It is like Obligation in XACML.)

- Prateek: the way the schema is written, an assertion could have 
  multiple instances of this element
- this has no meaning, so do we need to do anything about it
- Scott: is this the reason the timestamp stuff was moved out of 
  conditions and into the wrapper?
- interesting similarity, but don't think so
- there's no schema mechanism to enforce single cardinality
- Hal: would favor text saying SHOULD be no more than one
- Prateek: so need to add text to section 2.3.2.1.4
- [MOTION] Add the following text to section 2.3.2.1.4:
  "Issuing authority SHOULD NOT include more than one DoNotCache 
  condition element in an assertion " and "Relying parties MUST 
  interpret multiple DoNotCache elements as equivalent to one"
- [VOTE] no objections
- Prateek: in next item, editorial parts seem clear
- we have more substantive points
    - we have notion of condition validity, with processing rules
- Hal: proposes that it always be considered to be valid
- [MOTION] add the following text to section 2.3.2.1.4
  "for the purposes of determining the validity of the conditions 
  element, the DoNotCache condition is considered to always be valid"
- Irving: good, this covers something previously bothersome about how
  this condition was different
- [VOTE] no objections
- [ACTION] Rob to make DoNotCache updates in docs
- CLOSED
 
>
>    Issue sent this morning by Rob
>    < http://lists.oasis-open.org/archives/security-services/
>      200305/msg00104.html >
>

- Rob: a developer pointed out (around lines 1114-1118 of draft spec),
  element/attribute conflict in definition/description of AuthN method
- Prateek: doesn't think cardinality was expected to be greater than 1
- is it adequate to replace "element" with "attribute" in text?
- Rob: can't query on multiple types, right?
- Scott: believes you can
- Rob: can't query for authN statements that have both
- Jahan: believes there was only expected to be one per authN statement
- Rob: prefers just changing text to "attribute", but just wanted to 
  be sure of impact
- [MOTION] to change authN method description from element to attribute
- Jahan: should this be added to errata?
- seems like it should
- Rob will make change, and notify Jahan of which rev the change went
  it (will be rev 11)
- [ACTION] Jahan to add authN method attribute fix to errata
- [ACTION] Rob to make authN method attribute fix in docs
- [VOTE] no objections
- CLOSED

>
>    #0040 Editorial comments on SAML 1.1 document set
>    < http://www.oasis-open.org/archives/security-services/
>      200305/msg00095.html >
>    < http://www.oasis-open.org/archives/security-services/
>      200305/msg00096.html >
>

- Prateek: we've dealt with the DoNotCache issues
- these seem to be low level and assignable to people to correct
- Prateek will take the conformance-related comments and work through
  them
- Rob: has recommendation on keyInfo text, but is different than
  Frederick's

>
> 2. Review of time-line and next steps (revisited)
>    < http://lists.oasis-open.org/archives/security-services/
>      200304/msg00133.html >
>

- Prateek: all we need to do is ensure that before next call, we have
  all changes accepted and published in the repository
- Rob: true, but applies for normative issues, because we can make
  non-normative changes later
- Rob: ok with making ID type changes discussed earlier, is anyone else
  not ok with that?
- no objections
- Rob: current drafts have no changebars, so is there anyone who would
  like to see the entire set of differences?
- Irving: had been tempted to do that with Word's diff tool, but feared
  it would produce something unreadable
- Rob: tried it on a few docs, and it came out ok
- will post them

> 
> 5. Adjourn
>

- Adjourned


----------------------------------------------------------------------

Attendance of Voting Members:

  Irving Reid Baltimore
  Hal Lockhart BEA
  John Hughes Entegrity Solutions
  Carlisle Adams Entrust
  Scott Cantor Individual
  Bob Morgan Individual
  Padraig Moloney NASA
  Prateek Mishra Netegrity
  Frederick Hirsch Nokia
  Senthil Sengodan Nokia
  Charles Knouse Oblix
  Steve Anderson OpenNetwork
  Simon Godik OverXeer
  Rob Philpott RSA Security
  Jahan Moreh Sigaba
  Bhavna Bhatnagar Sun
  Jeff Hodges Sun
  Emily Xu Sun


Attendance of Observers or Prospective Members:

  Jason Rouault HP
  Krishna  Sankar  Cisco
  Don Flinn Individual


Membership Status Changes:

  Robert Griffin Entrust - Lost voting status due to inactivity
  Clifford Thompson Individual - Lost voting status due to inactivity
  Steven Lewis Booz Allen Hamilton - Granted voting status after call

--
Steve