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