OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: RE: [security-services] Minutes for Telecon, Tuesday 13 May 2003


Addition to the minutes - I believe Prateek took an action item to update
the conformance spec to reflect Nishimura Toshihiro's comments.

Rob Philpott 
RSA Security Inc. 
The Most Trusted Name in e-Security 
Tel: 781-515-7115 
Mobile: 617-510-0893 
Fax: 781-515-7020 
mailto:rphilpott@rsasecurity.com 


> -----Original Message-----
> From: Steve Anderson [mailto:sanderson@opennetwork.com]
> Sent: Tuesday, May 13, 2003 4:19 PM
> To: oasis sstc (E-mail)
> Subject: [security-services] 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


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