[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] Minutes for Telecon, Tuesday Jan 29, 2002
Minutes for SSTC Telecon, Tuesday Jan 29, 2002
Dial in info: +1 334 262 0740 #856956
Minutes taken by Steve Anderson
>
> Main Theme: Issuing Last Call Drafts
>
>
> 1) Roll Call
>
- Attendance attached to bottom of these minutes
- Quorum achieved.
>
> 2) Vote on document readiness to enter last-call (target of 1 Feb
> 2002)
>
> - I expect we will re-order this item and move it below Issue
> Resolution
>
- [Vote] moved to end of call. No objections.
- Hal proposes closing of non-controversial issues
- should be covered in item G
>
> 3) Issue Resolution - discussion and votes
>
> Key Issues to resolve prior to last call.
>
> A) Stephen Farrell's note:
>
> < http://lists.oasis-open.org/archives/security-
> services/200201/msg00168.html >
>
> A.1) use of unbounded
>
> candidate resolution: schema will retain unbounded, conformance
> document will outline minimum expectations.
>
> < http://lists.oasis-open.org/archives/security-
> services/200201/msg00191.html >
>
- Joe: no detailed text posted on list
- proposes voting on keeping candidate resolution, pending text
- BobG: who would be responsible for text?
- Joe: BobG for conformance
- Hal: will set minimum expectation on receiver?
- Joe: correct
- [Vote] no objections
>
> A.2) NotOnOrAfter
>
> healthy debate on list, would like to entertain a motion with
> final resolution of this topic. Failing to reach consensus,
> would like a vote on ability to issue last call with this item
> pending.
>
> < http://lists.oasis-open.org/archives/security-
> services/200201/msg00192.html >
>
- Phill: suggests treating as last call issue
- will leave at status quo for now
- Joe: agrees
- Hal: sees many separate issues wrapped up in this item
- Prateek: suggests splitting into 2 separate issues
- SAML vs. X509
- minimum tweaking of dateTime datatype
- Joe: leave SAML vs. X509 for last call
- Hal: proposes retaining text as is, leaving first issue (semantics)
to be left open for last call
- [Vote] no objects
- Joe: 2nd issue (time granularity, timezone) ...
- Irving: current text leaves enough flexibility for implementations
to get it wrong
- Gil: what's downside of requiring UTC?
- Eve: cost of converting
- Irving: prefers sender convert, so sender is to blame for incorrect
conversions
- Joe: sees consensus building around using UTC
- Hal: still concerned about granularity
- Phill: concerned that using libraries that emit valid XML will
require modifying those libraries according to this profile to only
speak UTC
- Eve: we can extend the data type with our own requirements
- RLBob: dateTime is broken in XML
- Joe: can we go to last call without addressing this?
- Irving: believes this will hold up last call
- Hal: does this apply to first issue (semantics) too?
- Irving: doesn't think so
- [Action] Prateek to write up issue
>
> A.3) Specification of comparison functions
>
> Expecting a brief detailed proposal on mailing list prior to
> conference call. Minimally expecting that the specification for
> strings dis-allows internal semantics to be processed by SAML
> processor (e.g., "Bill" is not equal to "Bill or Bob")
>
- Irving sent text to list
- left out discussion of attribute value normalization
- all white space turned to spaces
- all contiguous spaces are compressed into single space
- Eve: we should also refer to XML information set spec
- will send link to list now
- Irving: possibility of conflict with LDAP, which usually matches
ids using case-insensitivity
- Joe: any objections to this being the approach we use (effectively
a binary comparison)?
- no objections
- Hal: is conversion to Unicode that is discussed in email posting well
defined for all code sets?
- Irving: perhaps not
- Hal: can we say all will fail safe?
- Irving: hard to say
- Irving: would like a paragraph at top suggesting use of UTF8
- Scott: not sure what "SHOULD" language buys
- Irving: not sure if we can push "MUST" through
- Jeff: uncomfortable with case-insensitivity
- clarifying point: suggesting binary comparison of two items that are
in same encoding scheme?
- Eve: doesn't XML mandate use of UTF8 and UTF16?
- Eve: Unicode *is* the XML char set, but it is not an encoding. XML
mandates support of UTF8 for encoding, which should support all
Unicode
- ... but perhaps not? ... more discussion ...
- Joe: wants to close discussion on this topic
- going back to motion to include this text and review during last call
- [Vote] no objections
- [Action] Irving to work with Phill to get text included
>
> B) RespondWith
>
> < http://lists.oasis-open.org/archives/security-
> services/200201/msg00136.html >
>
> Phill was to submit proposal on clarification to list.
>
- Phill just sent text, so this gets pushed toward end of call
>
> C) MultiValue Attributes
>
> < http://lists.oasis-open.org/archives/security-
> services/200201/msg00178.html >
>
> Net result of discussion is to defer?
>
- RLBob: candidate solution sent to list by Scott
- motion is to add maxOccurs=unbounded to attributeValue
- after brief explanation, Eve supports
- [Vote] no objections
- [Action] Scott to work with Phill to incorporate "3rd option" from
email
>
> D) Issue DS-9-06 - Locating Authorities - text andschema changes
>
> < http://lists.oasis-open.org/archives/security-
> services/200201/msg00205.html >
>
- Scott's
- submitted text after conferring with Prateek
- no responses posted
- Joe: Prateek, satisfied
- Prateek: has reviewed, is satisfied
- Eve: objects to wording of "binding protocol"
- Prateek: should be "Protocol Binding"
- Eve: ditto for "binding attribute"
- second one (?) should be "binding"
- third one (?) should be "location"
- [Vote] no objections
- [Action] Scott to incorporate changes here and submit to list, and
Phill will incorporate that into doc
>
> E) Issue DS 9-10: Schema and text for IssueInstant in
> Request/Response
>
> < http://lists.oasis-open.org/archives/security-
> services/200201/msg00194.html >
>
- Scott: consensus on Request, no consensus on adding to Response
- doesn't serve any present purpose, but may server a future purpose
- proposes adding to both for symmetry
- BobB: agrees with adding it to Response
- Scott: there was "muddiness" in proposal, looking for guidance
- e.g. signatures and timestamping, bindings, etc
- Eve liked bindings section, would like to keep in proposal
- Joe: "muddiness" can be worked out during last call
- [Vote] no objections
- [Action] Scott to tidy up and get with Phill & Prateek for inclusion
>
> F) Anders Rundgren: XML schemaLocation in core25
>
> < http://lists.oasis-open.org/archives/security-
> services/200201/msg00171.html >
>
>
- Joe: seems non-normative
- Eve: this is supposed to be a hint
- Joe: can this be a comment in schema, rather than compiled element?
- Eve: thinks it would be best as an HTTP URI
- Hal: can understand document referencing schema, but why does schema
reference schema?
- samlp references saml
- Phill: can't verify schema until it's published, catch-22
- Scott: schema lookup is incredibly broken right now
- Scott: this shouldn't hold up last call
- Joe: thinking is to turn this into URL and see if there is any way
to improve during last call
>
> B) RespondWith -- REVISITED
>
> < http://lists.oasis-open.org/archives/security-
> services/200201/msg00136.html >
>
> Phill was to submit proposal on clarification to list.
>
- Irving not comfortable with this approach
- If this doesn't constrain responder's behavior, receiver must still
include logic that it was trying to avoid
- Phill: should RespondWith be mandatory?
- consensus moving that way
- Prateek: (clarifying) Even if responder can respond to the request,
but cannot conform to RespondWith, it must return error
- BobB: suggesting a success return code that expresses that there is
more that could have been returned had the RespondWith setting been
different
- ... more discussion ...
- Joe: not near consensus, wants more discussion on list, and to
follow up on this this week
- Jeff: wants background from Phill why this is really necessary
- [Action] Phill to provide more text
>
>
> 2) Vote on document readiness to enter last-call (target of 1 Feb
> 2002) -- REVISITED
>
- Joe: before vote, wants discussion
- doesn't believe we are ready for last call on Friday, Feb 1
- thinks we need one more call, plus another rev of docs reflecting
that call
- Disagreement?
- none
- So we won't hit Feb 1
- targeting Wed Feb 6
- will have con call Feb 5, where we will vote
>
> G) Remaining Issues from Hal's tentative resolution set:
>
- Hal: sent msg to list this morning
- should clear deck to <20 issues
- moves that we close and defer issues as listed in this morning's
email
- Jeff: hasn't had chance to review
- Hal: where he & Jeff disagreed, he isn't proposing final disposition
- the list of issues here in agenda does *not* reflect list in Hal's
email
- Joe: so, defer vote to next week
- Jeff: trust Hal, just wants to be clear on what we're voting on
- list to close does *not* include any with controversy
- URL of Hal's msg:
< http://lists.oasis-open.org/archives/security-
services/200201/msg00227.html >
- [Vote] No objections
>
> - DS-4-08 anyAttribute
>
- discussion ...
- Eve agrees to close this and send new issue
- Hal: proposes we close this
>
> - DS-9-05 RequestAttributes
>
- Simon agrees to differ
>
> - DS-9-10 IssueInstant in Req&Response
>
- this was just a typo, shouldn't have been an issue in the first place
>
> - DS-11-01 MultipleSubjectAssertions
>
- Jeff: core lines 575-576 states that multiple subject identifiers
SHOULD NOT point to multiple principals
- there was some intent here for simplification
- appears that Java's JAAS uses subject/principal terminology exactly
opposite ours
- Irving: reason for bringing this up originally was that we've never
defined processing that receiver is supposed to do
- Hal: was intended to be semantically equal to creating 2 assertions
that differ only in subject
- Eve: looking at 2.4.2.1, thinks Subject element is riddled with bugs
-
>
> - DS-12-06 RequestALLAttribs
>
- Eve: lines 1008-1009 of core-25 needs wording fixed
- should be msgs in archive with better wording
>
> - DS-14-07 BearerIndication
>
- Joe to Phill: know why this was dropped?
- seems to have been inadvertent
- [Action] Phill to restore
- Hal: 2 more issues to raise that shouldn't prevent going to last
call
- will submit to list today
>
> 5) Adjourn
>
- Joe: much ambiguity in discussions, and new issues appearing
- please be sensitive to true need in new issues
- Hal: issues can be raised and suggested for deferral
- trying to setup focus call Friday Feb 1
- Adjourned
-----------------------------------------------------------------------
Attendance of Voting Members:
Allen Rogers Authentica
Irving Reid Baltimore
Simon Godik Crosslogix
Gil Pilz E2open
Hal Lockhart Entegrity
Carlisle Adams Entrust
Robert Griffin Entrust
Don Flinn Hitachi
Joe Pato HP
Jason Rouault HP
Chris McLaren Netegrity
Prateek Mishra Netegrity
Jeff Hodges Oblix
Charles Knouse Oblix
Steve Anderson OpenNetwork
Darren Platt RSA
Jahan Moreh Sigaba
Eve Maler Sun
Aravindan Ranganathan Sun
Emily Xu Sun
Marlena Erdos Tivoli
Bob Morgan UWashington
Phillip Hallam-Baker Verisign
Thomas Hardjono Verisign
Attendance of Observers or Prospective Members:
Rob Philpott RSA Security
Sridhar Muppidi Tivoli
Bob Blakley Tivoli
Scott Cantor OSU
Membership Status Changes:
Xin Wang ContentGuard - granted voting status after call
Marc Chanliau Netegrity - lost voting status due to missing 3rd
consecutive meeting
--
Steve
begin:vcard n:Anderson;Steve tel;fax:727-561-0303 tel;work:727-561-9500 x241 x-mozilla-html:FALSE url:www.opennetwork.com org:OpenNetwork Technologies version:2.1 email;internet:sanderson@opennetwork.com title:Product Architect adr;quoted-printable:;;13577 Feather Sound Drive=0D=0ASuite 390;Clearwater;Florida;33762;USA x-mozilla-cpt:;-6352 fn:Steve Anderson end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC