[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"
category
- 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
warranted
- [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
loose?
- 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
character
- 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
1317)
- 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 2.3.2.2
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
removed
< 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
published
- 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
bindings
- 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
profile)
- 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
--
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