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 19 Mar 2002

Minutes for SSTC Telecon, Tuesday 19 Mar 2002
Dial in info: +1 334 262 0740 #856956
Minutes taken by Steve Anderson

> 1. Roll call

- Attendance attached to bottom of these minutes
- Quorum achieved.

> 2. RSA IPR Questions

- Prateek: speaking as engineering member of Netegrity, raises concerns
  in 2 areas
    - situation where some new technology utilizes SAML for some
      small piece, and wants to patent it, this needs clarification
      on impact from RSA
    - if any enterprise is selling a toolkit that utilizes SAML, the
      end user of products must apply to RSA for a license -- this
      will have considerable impact
- Joe: in paragraph 2, what is reach of reciprocal agreements?
- agrees with Prateek about paragraph 3
- Joe asks Burt/John if he is reading properly
- Burt: these are valid questions
- in second paragraph, intent is to cover things that are relevant to
  the essential use of SAML
- is not intended to cover all other technology in the product
- Prateek: so you will grant a license for the SAML process as long
  as other parties do the same?
- Burt: roughly, when one is using SAML for signed assertions (e.g. in
  SAML profile), they want cross licensing
- Joe: clarifying that this is all relevant to SAML v1.0
- Burt: have deliberately left out version numbers to be more flexible
- RLBob: there is ambiguity in what is SAML profile, as other parties
  can develop SAML profiles
- Hal: a profile can't be an OASIS spec unless it is voted on
- so this can be the distinguishing factor
- Burt: on second question (from 3rd paragraph) involving toolkits,
  reciprocal arrangement is intended to be developer-to-developer
- whether you are developing the product from scratch or from a
  toolkit, they expect the same reciprocal arrangement
- Not the same for "end user"
- Hal: so you are making a distinction between developing for sale vs.
  own use?
- not clear
- Joe: speaking as an "end user", most of my "end use" will be using
  toolkits to build web services, which puts me in the "developer"
- Hal: thinks issue is notice to RSA of use, noting JSR-155 project
- Prateek: is there any way paragraph can be designed in a flow-thru
  way, so end user doesn't have to return to RSA?
- Burt: if vendor wants to avoid end customers having to contact RSA,
  then vendors can make separate arrangements with RSA
- Jeff: reads this as statement of intent or terms, it is not a
  license, and it would be helpful if it were labeled as such
- Burt: fair enough, will do that

> 3. Issues

- Joe: asks Hal to run thru what happened recently
- Hal
    - re-issued issues list, with closed issues we voted on last week
    - decided to bundle in 4 outside issues that need champions
    - interesting part is status list
        - all of the stuff that was agreed upon and incorporated
          in latest docs (except Eve's suggestion on how to give
          credit) are listed in green
    - last week's vote to close/defer excluded too many items
        - specifically DS-14-14, DS-14-15, DS-14-16
    - status of 4 outside issues that lacked champions
        - 1 was championed by Hal, and recommended for deferral
        - 2 were answered by Phil & Prateek
        - 1 was dropped for lack of interest
    - Hal has new issues to bring up later in call
- Scott: had posted some status code proposal text, but didn't expect
  to have those in -28

- Joe: goal is to close this month
    - so proposals must have explicit text
    - any new issues MUST be offered today,
    - consider in issue discussion what would cause you to vote against
      the spec
- Hal to lead thru all red issues
    - DS-1-10 SubjectConfirmation Descriptions
        - Hal had proposed a resolution, and can create specific text
        - Irving: can they be removed from core and left to profiles?
        - Jeff: DS-1-13 are intertwined
        - Hal: they could be dealt with separately
        - general agreement (among those on call) that SubjectConf &
          AuthNMethod are distinct
        - Phill was primary dissenter, but is not currently on call
        - general agreement that lack of resolution would
    - DS-1-13
        - as in previous discussion, Phill primary dissenter
    - DS-4-12 URNs for Protocol Elements
        - Hal: this is only technically still open
        - RLBob: spoke with Karl
        - Karl agreed that use of "SAML" rather than "security-
          services" is appropriate
        - Joe: so is there a motion that we can vote on?
        - RLBob: moves that we adopt this as proposed, with allowance
          for editors to append to end of URNs whatever they feel is
        - [VOTE] no opposition, passed
    - DS-4-13 Empty Strings
        - Hal recalls some discussion, but no counterproposal
        - Scott: in general the issue is where SAML imposes additional
          requirements on format, should that be levied in schema or
          in text of the spec?
        - Prateek: by simply remaining silent on this, what do we
        - Irving: less of the validation would be done by XML parser
        - Scott: doesn't seem controversial
        - Prateek: doesn't think this is a blocking issue
        - implementors must decide what it means to have empty string
          for a required item, and if we change it later, it could
          have impact
        - Irving: a reasonable approach could be to define a new
          type, nonemptystring, and use it throughout spec
        - Jeff: is this something that should hold up the spec?
        - Motion to define a nonemptystring type, and a listing of all
          places for it to be used in spec (to be available tomorrow)
        - Scott: proposes that nonempty means at least 1 non-whitespace
        - Hal: is whitespace well defined across all char sets?
        - apparently so
        - starts leading down a rathole
        - RLBob: advocates just enforcing non-zero length, but leave
          content facet, e.g. whitespace, alone
        - motion to change all strings to nonemptystrings, and do
          sanity check to see if there are any places where string
          should be retained
        - [VOTE] no objections, passed
        - [ACTION ITEM] Scott to do sanity check to find any instances
          where string should be retained
        - similar situation with URLs/URNs
        - motion to apply same approach to URLs/URNs
        - [VOTE] no objections, passed
        - [ACTION ITEM] Scott to do same sanity check on URLs/URNs
    - DS-4-15 Common XML Attributes
        - Prateek: doesn't see this as blocking
        - motion to defer this
        - Hal: notes that these will be painful to change later
        - Rob: echoes sentiment
        - growing consensus that there's no burning motivation to do it
          now, and doing it later would make less sense
        - [VOTE] no objections, passed (deferred)
    - DS-8-06: Issuer Format
        - RLBob: just sent msg withdrawing this for lack of interest
          and time
        - moves to close issue
        - [VOTE] no objections, passed (closed)
    - DS-9-14: Malformed Request
        - Scott: in what sense malformed? won't validate? it's almost
          a bindings issue
        - if you can't make out the request id, how can it be echoed
          in error response?
        - Scott: can't mandate that a response be sent, and can be
          left to bind to stipulate, for instance, a SOAP fault
        - Hal: since there is always a surrounding protocol, it can
          make a response, without a SAML-level response
        - Hal: is this worth stating in core, under error handling that
          a malformed request can be dropped on floor, and that binding
          must handle a response
        - Joe: contends that responder can always drop on floor,
          simulating a comm failure
        - Hal: a core-level response could omit InResponseTo
        - motion to make InResponseTo optional, with a few lines of
          text explaining the specific case where this is necessary
        - [VOTE] no objections, passes
        - [ACTION ITEM] Scott will produce text
        - Hal: had claimed MS-5-04 was dead, but didn't realize there
          was a related change to core
    - DS-12-06: RequestALLAttrbs
        - Hal: feels leaving it as is is unacceptable, suggests use of
          keyword "ALL"
        - Rob: agrees. what about using wildcard rather than keyword
        - Hal: wildcard suggests possibility of regular expressions,
          which we don't want
        - Joe: agrees
        - Hal: Not sure how to do it in XML, particularly if there
          might be an attribute named "ALL"
        - Scott: believes that simplest approach is for absence of
          attribute designators to mean "ALL"
        - Needs explicit wording in spec (core-28 section 3.3.4 line
        - motion to treat absence of attribute designators to mean
          "ALL", and eliminate implementation discretion
        - [VOTE] no objections, passed
        - [ACTION] Hal to produce text for core-28 section 3.3.4
    - DS-14-19: Remove Advice
        - proposal was to remove Advice element, since there will be
          no motivation to derive a type from this
        - motion would be to remove <AdviceElement> and just stick
          with the wildcard, changing text in core section
          and in schema
        - Scott: offering to craft changes
        - [VOTE] no objections, passed
        - [ACTION ITEM] Scott to submit change text
    - DS-14-20: Reorder Conditions Contents
        - motion to make change as proposed in ELM-5, with friendly
          amendment that TargetRestrictionCondition has already been
          < http://lists.oasis-open.org/archives/security-services/
            200203/msg00042.html >
        - [VOTE] no objections, passed
        - [ACTION ITEM] Editors to incorporate
    - MS-1-03: Domain Component Terms
        - motion to correct as highlighted in issue text
        - [VOTE] no objections, passed
        - [ACTION ITEM] Editors to correct
    - MS-5-08: Publish WSDL
        - Irving: was never validated, and it should be before being
        - Hal: Does Emily (being a Sun employee) have any resources
          for validating this?
        - Hal: proposes that we make it an appendix to bindings doc
        - Joe: would like to propose as a committee doc, separate from
        - Irving: it is specific to the SOAP binding
        - Hal: since it is non-normative, what is value in making it a
          separate doc?
        - Joe: reacting in part to description of it being rapidly
          thrown together
        - Jeff: moves to defer it for now
        - [VOTE] no objections, passed (deferred)
        - msg reference is
          < http://lists.oasis-open.org/archives/security-services/
            200111/msg00022.html >
    - MS-5-07: SSO Confirmation
        - Jeff's response msg:
          < http://lists.oasis-open.org/archives/security-services/
            200203/msg00118.html >
        - RLBob also sent analysis in
          < http://lists.oasis-open.org/archives/security-services/
            200203/msg00121.html >
        - motion to accept proposal in Jeff's response msg
        - [VOTE] no objections, accepted
- Hal: people should take a look to see if

> 4. How to proceed from here

- Joe: feels we are in danger of not even reaching committee spec next
  week, much less get it in for next OASIS vote
- would vote NO as it stands now
- what we can do to assuage public perception is to get to committee
  spec and vote on it next week
- Scott: still has status code issue that needs vote
- Joe: might be able to do it here next
- Joe: we can freeze and package up and give to Karl, even though it
  can't be ratified until July 31st
- can proceed with interop efforts and other activities (e.g. SOAP
- would also make more comfortable with quality of attestations

- Scott's status code issue
    - original proposal
      < http://lists.oasis-open.org/archives/security-services/
        200202/msg00160.html >
    - Eve's response
      < http://lists.oasis-open.org/archives/security-services/
        200202/msg00161.html >
    - Scott's response
      < http://lists.oasis-open.org/archives/security-services/
        200202/msg00162.html >
- Hal's new issues include one on SubjectConfirmation that can lead to
  a security attack
    - can be used to effectively guess password
- Scott: So it seems that it is unlikely to have a spec ready for vote
  next week
- RLBob: not ready to give up on date yet
- Scott would like to get his status code stuff out of the way
- motion to incorporate contents of Scott's original status code msg
- [VOTE] no objections
- [ACTION ITEM] Scott to resend proposed text
- [ACTION ITEM] Hal to send his issues and some proposals to list
- [ACTION ITEM] Phill to make change from AuthenticationLocality
  to SubjectLocality

> 5. Adjourn

- Adjourned


Attendance of Voting Members:

  Allen Rogers Authentica
  Irving Reid Baltimore
  Krishna Sankar Cisco
  Hal Lockhart Entegrity
  Joe Pato HP
  Jason Rouault HP
  Marc Chanliau Netegrity
  Prateek Mishra Netegrity
  Charles Knouse Oblix
  Steve Anderson OpenNetwork
  Rob Philpott RSA Security
  Jahan Moreh Sigaba
  Jeff Hodges Sun
  Emily Xu Sun
  Bob Morgan UWashington

Attendance of Observers or Prospective Members:

  Scott Cantor OSU
  Tim Moses Entrust
  Burt Kaliski RSA
  John Linn RSA


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