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

> 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
- ... 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
- 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
- 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, 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
    - 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


tel;work:727-561-9500 x241
org:OpenNetwork Technologies
title:Product Architect
adr;quoted-printable:;;13577 Feather Sound Drive=0D=0ASuite 390;Clearwater;Florida;33762;USA
fn:Steve Anderson

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

Powered by eList eXpress LLC