[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Minutes for Telecon, Tuesday 11 March 2003
Added attendance info for:
- Nataraj Nagaratnam IBM
--
Steve
-----Original Message-----
From: Steve Anderson
Sent: Thursday, March 13, 2003 3:23 PM
To: OASIS WSSTC (E-mail)
Subject: [wss] Minutes for Telecon, Tuesday 11 March 2003
Minutes for WSSTC Telecon, Tuesday 11 March 2003
Dial in info: +1 877 302 8255 #3578623
Minutes taken by Steve Anderson
======================================================================
Summary
======================================================================
Votes:
- Minutes from 25 February 2003 meeting accepted (unanimous)
- We instruct the editors to clarify the language around timestamp
recipient, and to clarify handling of expiration after interop
(unanimous)
- To push this [discussion of defining a type for tokens] out until
after interop drafts (one objection)
- To freeze current drafts (listed below) as basis for interop, and
only make tweaks as necessary for interop (unanimous)
- WSS: SOAP Message Security, Draft 11
- WSS: Username Token Profile, Draft 2
- WSS: Kerberos Token Profile, Draft 3
- WSS: X509 Token Profile, Draft 3
- WSS: SAML Token Profile, Draft 6
- WSS: XrML Token Profile, Draft 3
- WSS: XCBF Token Profile, Draft 1
New (General) Action Items:
- Editors to clarify the language around timestamp recipient, and to
clarify handling of expiration
- Chris will write up scenarios details and send to list
Issues List Action Items & Status Updates:
- 69: DEFERRED to post-interop revision
- 70: DEFERRED to post-interop revision
- 71: DEFERRED to post-interop revision
- 72: DEFERRED to post-interop revision
- 73: DEFERRED to post-interop revision
======================================================================
Raw Notes
======================================================================
>
> Agenda:
>
> 1. Roll call
>
- Attendance attached to bottom of these minutes
- Quorum achieved
>
> 2. Review minutes from previous meeting (2/25/2003)
> < http://lists.oasis-open.org/archives/wss/
> 200302/msg00067.html >
>
- [VOTE] unanimous consent, accepted
>
> 3. Outstanding interop test issues (do we have any?)
>
- John: new issues 69-72 need to be covered
- Jerry: had sent an issue that hasn't been added
- John: will add
- going thru issues
- 69: from Peter Dapkus
- recently joined group
- didn't see enough in keyIdentifier to implement
- John: is this an issue that must be resolved for the interop
test
- Chris: this hasn't been identified as an interop scenario
- suggests postponing until after interop
- editors should respond to Peter's email on the list
- Ron: aren't keyIdentifiers the preferred reference form for a
token?
- keyIdentifier text should be moved into profiles, instead of
appendix
- Ron: specific profiles must describe how to use keyIdentifier
- Chris: thinks we should defer this until we close on the X509
profile
- for the interop demo, we can fix the cert used on both sides
- question of how much we are going to bite off in this test
- the keyIdentifier can be a constant
- Ron: thought we would want to include a cert, and use
keyIdentifer to point to it
- Chris: what do others think?
- Martijn: agrees with keeping first demo simple
- Ron: what are we testing? a validated signature?
- Martijn: timestamp, encryption, c14n, ...
- Chris: thinks this will be a big interop step
- Chris: suggests not putting cert in header, instead, use STR
with a keyIdentifier
- ??: suggestion to use ID references
- Chris: great idea, and we can deal with keyIdentifier in next
draft
- you only need keyIdentifier if the token isn't in the msg
- Peter: if we don't use keyIdentifier in the demo, he's fine
with deferring
- Ron: didn't think we could avoid using keyIdentifiers, but
understanding of them is changing
- DEFERRED
- 70: from Eric Gravengaard
- John: these all look like post-interop issues
- first part of issue deals with faults
- second part deals with use of mustUnderstand
- Chris: don't think we need to worry about mustUnderstand for
the interop
- DEFERRED
- 71: from Ron Monzillo
- inconsistencies with MUST/SHOULD for token pre-pending
- John: this could impact interop
- Ron: thinks this is a high-level question
- John: for interop, we can agree that this is a MUST, then
afterwards, debate it as a MUST/SHOULD
- Ron: what was intent?
- John: it should be helpful to order in this fashion, but there
could possibly be reasons an implementation couldn't do it
- Hal: there's no cryptographic assurance to this
- John: true
- proposal: for interop demo, make it a MUST, then have this
debate afterward
- Hal: if msg passes thru nodes, each adding tokens properly,
there's no assurance that someone didn't shuffle them, so
just want to make sure no one counts on this
- Hal: agrees with John's suggestion
- Ron: given Hal's comments, thinks this ought to be a SHOULD,
since all it is there for is improving performance
- Peter: seems to complicate interop to say SHOULD vs. MUST
- John: trying to come to closure, returns to his proposal, and
is agreeable to Ron's suggestion to make it a SHOULD in the
spec after interop
- DEFERRED
- 72: from Peter Dapkus
- dependency on namespace, particularly with timestamps
- John: thinks this is deferrable
- Peter: as long as interop doesn't use timestamp
- John: doesn't agree
- Chris: points out confusion over this being an external
dependency, since we define wsu
- John: URIs can just be used, and we can debate their
correctness later
- Jerry: returns to fact that wsu is defined by us
- Peter: will look at it again
- moving on to issue with 'expires'
- seems to introduce risk
- John: when a recipient gets a msg, it has to deal with clock-
skew
- cryptographically, we can deal with alterations of the msg
- if we trust the other party, we can determine if we trust the
timestamp
- Hal: exact text is less specific than this discussion suggests
- John: the context of the timestamp dictates interpretation, and
in this case, it is WS-Security, which we control
- Hal: wording is not very clear
- John: motion to fix recipient and sender wording
- Ron: what lines?
- Hal: in section 10, lines 1262 in version 11
- John: motion is around interpretation of 'expires'
- <more explanation>
- Jerry: we should not leave the return of a fault in the case of
an expiration
- Ron: disagrees, should be up to policy
- John: also have to be careful mandating error responses to
protect against Denial of Service attacks
- Tony: can to the Security Considerations some text around not
dictating error responses
- [MOTION] For purposes of interop testing, we can move on. We
instruct the editors to clarify the language around timestamp
recipient, and to clarify handling of expiration after interop
drafts
- [VOTE] unanimous
- missed an issue from Jerry -- becomes #73
- Jerry: had to do with what tokens are allowed within a token
reference
- had made a motion to add an embedded reference, but this isn't
well-defined
- John: do you see this as an interop issue?
- Jerry: depends on whether we'll use embedded tokens
- Chris: that's not planned for interop
- Ron: but we want a pretty firm schema going into interop
- Chris: this shouldn't require a schema change
- Ron: not convinced
- Chris: expects we'll use an 'any', and have to address it with
text
- Ron: can't we define a type for this?
- Chris: because we want to leave open the definition of other
token types, that would be problematic
- John: [MOTION] to push this out after interop drafts
- Ron: wants us to have a schema with such a fundamental issue
- suggests a type, called Security Token, and have within it an
any
- John: already have this flexibility at the top
- Ron: but you can't distinguish a token-'any' from any other
'any'
- Chris: questions need to have a schema that doesn't need
changes before interop, since interop is supposed to uncover
needed changes
- Ron: thinks this is a big hole and we don't seem interested in
dealing with it
- concerned that interop will lead to proliferation of
implementations, which will make changes less acceptable
- Chris: looking for a vote on motion
- Jerry: will we stop discussion on this until after interop?
- Chris: no, just wants to label this doc set for interop, then
we can get coding against it
- [VOTE] one objection, passes
>
> 4. Discussion of updated specs
>
- Kelvin: OASIS shut down FTP in anticipation of switch to new system,
so the docs may remain stale for a while
- Chris: thinks issues 66 & 68 are pending review
- Tony: update on latest doc (draft 11)
- takes care of open issues, including embedded tokens, and some
wording clarification for Ron & Frederick
- Chris: can we close 66 & 68?
- Jerry: has editorial issue with embedded text, which says it contains
a SAML assertion, but the example actually doesn't
- Chris: can add to editorials to change after interop
- Ron: wants to comment on 66, which isn't an interop issue. Did we
just close it?
- Chris: no, just deferred
- Ron: concerned with 'post-interop' approach, for instance SAML interop
can't happen until after this interop
- Chris: true
- Kelvin: agenda includes discussion of scenarios
- Ron: right, but we're eliminating options for that discussion
- Kelvin: nothing is set in stone, and we can come back to these
- Ron: what is correct order of tokens and processed data that uses that
token?
- Chris: intent is to process tokens before needing to use them in
processing other message elements
- jumping to agenda item 6
>
> 6. Discussion of scenarios for interop test
>
- Kelvin: let's discuss Chris' posted scenarios
- Chris: was proposing a simple set of steps to test the core stuff, then
add a few variations
- Zahid had sent additional scenarios, which are good, but are more
complex than we probably want for the first test
- We can have another interop event with more options
- Martijn: has issue with 2nd scenario, since many systems won't have
access to passwords, either in cleartext or in hashed form
- Ron: wants to make sure scenarios are something everyone can do
- Tony: not everyone will choose to implement all scenarios, some will
implement clients vs. servers
- Ron: regarding passwords, doesn't seem like sending them over SSL is
really adding anything, and that this is the place to do encrypted pwds
- Chris: the interop isn't to justify aspects of spec, it's to flesh out
basic elements, many of which mirror what is done in other ways now
- Ron: proposes replacing #2 with sending the password encrypted for the
server, without SSL
- Chris: thinks this is great
- Peter: doesn't think this is useful, because you're just swapping one
secret for another
- Martijn: suggests adding a timestamp, and a nonce
- Chris: actually, you'd want to encrypt the password hash, rather than
password itself, but we can work that out
- Jerry: wants more msg detail
- Chris: intends to do that, but only after we agree at highlevel
- Chris: looking for feelings on these 4 (including Ron's suggested
change to #2)
- Ron: actually this is only 3, with #4 being 'variations', but doesn't
think we need those variations
- Chris: #4 would be #3 with different c14n and encryption alg
- Ron: do we need different c14n?
- Chris: we need to cover standard & exclusive c14n
- Ron: shouldn't exclusive be preferred?
- Chris: yes, but standard is very prevalent
- <more discussion>
- Chris: we can drop standard c14n, but thinks it will be unfortunate for
overall interop
- also concerned that if we limit this too much, the demo will be done by
lunch
- Hal: suggests we flesh out #4 further on the list
- Chris: agrees
- discussion of un/willingness to participate if all scenarios can't be
performed
- general agreement to further expound on #1, #3 & #4 from Chris' email,
plus Ron's altered #2
- Jerry: has been waiting to comment on #2, specifically about the
response being signed, which should be a separate test
- doesn't want to use SSL at all
- wants a request with no security header, and a response that does have
a security header
- ??: re-iterated desire not to use SSL, which will only complicate event
- Chris: fine with that
>
> 5. Do we now have an "interop draft"?
>
- Chris: thinks we do, do others agree?
- [MOTION] To freeze current drafts as basis for interop, and only make
tweaks as necessary for interop
- Tim: had an issue with X509 profile, which haven't been addressed
- Chris: thinks they were, in revision ~2 weeks ago
- Peter: still doesn't see usefulness in encrypting username/pwd, but
doesn't feel strongly about it
- [VOTE] no objections
- [ACTION] Chris will write up scenarios details and send to list
- Jerry: does not want to see documents on web site labeled 'interop
draft'
- we've not agreed to that, we've just agreed to use particular drafts for
this event
- Chris: fine with that
>
> 7. Discussion of next F2F place and time
>
- out of time, not discussed
>
> 8. Other business
>
- none
>
> 9. Adjourn
>
- Adjourned
-----------------------------------------------------------------------
Attendance of Voting Members:
Don Adams TIBCO
Zahid Ahmed Commerce One
Steve Anderson OpenNetwork
Lloyd Burch Novell
Paul Cotton Microsoft
Venkat Danda IONA Technology
Peter Dapkus BEA
Martijn de Boer SAP
Thomas DeMartini ContentGuard
Yassir Elley Sun Microsystems
Don Flinn (individual)
Eric Gravengaard Reactivity
Frederick Hirsch Nokia
Maryann Hondo IBM
Merlin Hughes Baltimore Technologies
Chris Kaler Microsoft
Charles Knouse Oblix
Yutaka Kudo Hitachi
Guillermo Lao ContentGuard
Kelvin Lawrence IBM
Hal Lockhart BEA
Ronald Monzillo Sun Microsystems
Bob Morgan (individual)
Tim Moses Entrust
Anthony Nadalin IBM
Nataraj Nagaratnam IBM
Toshihiro Nishimura Fujitsu
TJ Pannu ContentGuard
Rob Philpott RSA Security
Hemma Prafullchandra VeriSign
Ed Reed Novell
Irving Reid Baltimore Technologies
Peter Rostin RSA Security
Jason Rouault HP
Rich Salz Data Power
Vipin Samar Oracle
Jerry Schwarz Oracle
Senthil Sengodan Nokia
Shawn Sharp Cyclone Commerce
John Shewchuk Microsoft
Frank Seibenlist Argonne National Lab
Gene Thurston AmberPoint
Ganesh Vaideeswaran Documentum
Sirish Vepa Sybase
Sam Wei Documentum
John Weiland Navy
Attendance of Observers or Prospective Members:
John Hughes Entegrity
?? ?? Perficient (expecting email for identification)
Membership Status Changes:
Toufic Boubez Layer 7 -- Lost voting status due to inactivity
Mark Nobles LMI -- Lost voting status due to inactivity
Rajesh Raman BEA Systems -- Lost voting status due to inactivity
--
Steve
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]