[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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]