[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wss] Minutes for Telecon, Tuesday 25 February 2003
Minutes for WSSTC Telecon, Tuesday 25 February 2003
Dial in info: +1 (405) 244-5555 #6921
Minutes taken by Steve Anderson
======================================================================
Summary
======================================================================
Votes:
- Minutes from 11 February 2003 meeting accepted (unanimous)
- To redefine the transform for Signing Tokens (see section 8.3 in
draft 10 of the core) such that it only defines how a referenced
(by ds:Reference attributes or by XPath node-set)
SecurityTokenReference is dereferenced to get the SecurityToken to
be digested. The STR-transform will no longer be used to directly
reference a SecurityToken by including a STR within the transform.
(unanimous)
- Add subsection to section 7 to define the case where the a security
token can be a subelement of a STR (unanimous)
New (General) Action Items:
- Editors to incorporate change voted on for Signing Token transform
Issues List Action Items & Status Updates:
- 60: CLOSED
- 61: CLOSED
- 66: PENDING
- 68: PENDING
======================================================================
Raw Notes
======================================================================
>
> Agenda:
>
> 1. Roll call
>
- Attendance attached to bottom of these minutes
- Quorum achieved
>
> 2. Review minutes from previous meeting (2/11/2003)
> < http://lists.oasis-open.org/archives/wss/
> 200302/msg00030.html >
>
- [VOTE] unanimous consent, accepted
>
> 3. Kavi migration update
>
- general warning of upcoming go-live date: 3/13
- everyone should get their own userid/password before that
- everyone should verify their expected TC membership status
- send email to Steve Anderson for inconsistencies for WSSTC
>
> 4. Issues list
>
- Will take pass through pending items
- 60
- Thomas: there were a few things overlooked, which he mailed
Tony about
- Tony: has updated next draft with those changes
- Ron: requested copy of Thomas' msg
- CLOSED
- 61
- Frederick was to review
- Frederick will be late to call today, will pick up after he
joins
- 66
- Action was for people to go off and review the transform
- Tony: this isn't the latest draft, and there is one nit
from Frederick
- Hal: what is the number of latest draft?
- Tony: 10
- Kelvin: should be on list, in an email from Sunday night,
but it's not yet linked on the web site
- Ron: has had questions from within Sun about not using standard
transforms like XPath
- Chris: in some cases XPath may be difficult for referencing
tokens
- Ron: there are two halves to this, a dereferencing transform and
a data reference for security tokens
- Tony: what is the advantage to going the XPath route?
- Ron: (described an interoperability issue)
- Ron: have to be able to data-reference anything, including
a security token, which we can with XPath
- have to reference what you want to sign
- could be a STR, using normal XPath form
- Chris: but you may not be able to
- suppose you have a header with 6 SAML tokens
- you could reference by index, assuming no one reorders them
- can't reasonably reference them by identifier with XPath
- Ron: boils down to the fact that we have this powerful XPath
that can reference anything anywhere, but we are building
another one
- Chris: extending it to reference anything anywhere becomes more
complex than using a specific, simple, well-known transform
for our specific referencing need
- Chris: XPath has a number of scenarios it works well for, such
as when an XML ID is available. We're just calling out
exceptions.
- Jerry: re-phrasing Ron's interoperability concern, thinks it
comes down to inventing new transforms, and the burden it
places on digit signature implementations
- believes that right approach is to make tokens uniform, and if
necessary, add a wrapper
- John: tokens will be non-uniform, as people define all kinds
of token types, and we want to be able to support them
- Tony: STRs are wrappers, so not sure why there is belief that
it is not
- (discussion of STR as wrapper)
- Paul: clarifying where we're at in this call
- Ron: doesn't object to the transform Chris developed, believes
that it solves one problem well, and wants to understand how
it solves a second problem
- Tony: one alternative is to in-line the token in a STR,
internally referencing a token
- Ron: doesn't that imply that you will need to reference this
STR from another STR
- do you need another transform for this?
- Chris: the STR would have an ID, and a simple transform that
looks for the STR's ID could be developed
- Ron: thinks we still need a dereferencing token so that STRs
can be pointed for purposes of signing the STR
- Frederick: asks for summary of what changed
- Chris:
- we can simplify the transform in the doc to say "don't
sign the STR, but sign what it references"
- [MOTION] To redefine the transform for Signing Tokens (see
section 8.3 in draft 10 of the core) such that it only defines
how a referenced (by ds:Reference attributes or by XPath
node-set) SecurityTokenReference is dereferenced to get the
SecurityToken to be digested. The STR-transform will no longer
be used to directly reference a SecurityToken by including a
STR within the transform.
- [VOTE] no objection
- [ACTION] Editors to incorporate the STR change
- Tony: doesn't see why we can't make it simpler by in-lining the
token
- Ron: would there be a transform?
- Tony: no
- Ron: doesn't see why it's necessary
- Jerry: it removes a level of indirection
- Ron: thinks this is just a wrapper, and you should just call it
such
- Jerry: [MOTION] to add to section 7 the ability to add a
security token as a child of a STR
- Ron: we don't have a type for security token
- Chris: we already have something to reference in a STR
- Jerry: the sub-element of the STR could be anything that could
have been found in the <Security> header, since there is no
security token type
- Ron: does anyone have a use today where they're directly
including a security token?
- Tony: not today, but he's tracking performance issues and this
would help greatly
- Ron: assuming that there is a type for security tokens (which
we don't) and that type exposed an ID, would this motion be
necessary
- Jerry: wouldn't be opposed to that
- Hal: we had this argument before, and we wanted to associate
attributes to the token, and unless you want to add that to
the token type, you still need the reference
- further, values for such attributes may differ by use, even for
the same token
- Ron: if we are literally including a token within a wrapper, why
not just create a token type, and if we do that, what is the
value of having the STR mechanism?
- Hal: thinks you need to pointer-type reference even with the
wrapper
- Ron: thinks that works fine if there can be an expectation that
each token exposes a consistent exterior, which the wrapper can
provide
- Ron: getting back to Jerry's motion, he doesn't object to
placing token literally within a STR, but he was questioning
the need for non-internal references, given the wrapping
ability being proposed, but ready to move on
- Hal: concerned about semantic confusion with STRs being used
in these two different ways
- (more discussion)
- [MOTION - restated] Add subsection to section 7 to define the
case where the a security token can be a subelement of a STR
- [VOTE] no objection
- PENDING
- 61 (Frederick on call now)
- Frederick: wording in doc is fine
- Thomas has made other wording issues, which Frederick can
address
- CLOSED
- 68
- summary of change was to clarify that there is no requirement
for servers to maintain access to cleartext passwords
- "shared secret" is the more appropriate term, rather than
password
- hashed values of original passwords could be used
- Jerry: is there a uniform way to express which shared secret
to use
- Chris: no uniform way, but could define QName values for this
- PENDING
>
> 5. Review of updated specs
>
- Chris: if there are issues (which block interop), send them to the list
>
> 6. Do we have an "interop draft" - vote
>
- Chris: we still have to develop scenarios (which he owes to the list)
for an interop event
- seems that the pending issues do not block an interop event
- Ron: are we changing the structure of an STR?
- Chris: we wouldn't likely involve that in this event
- any objections to current version being used as base for an interop
event?
- Hal: any ambiguities can be addressed in the event
- Do we want to address 66 & 68 first?
- Ron: wants to get schema stabilized
- [MOTION] Version 10 of current version, with issues 66 and 68
incorporated, and with a matching schema, will be used for an interop
event
- Ron: thought we would have use cases or a script before making such a
decision
- Hemma: thinks that in order to make progress, must start with minimal,
like username/password
- Hal: thinks there is no urgency to decide on this today
- we can proceed to the interop script
- Prateek: supports Hal's comment
- Tony: concerned at lack of traction
- Ron: thinks starting code requires notion of scenarios
- Chris: will do scenarios in next 24 hours, and Version 11 will be out
ASAP
- Tony: how many scenarios are we looking at?
- Chris: just a few, like username/password, a small X.509 case, maybe an
encryption case
- [MOTION WITHDRAWN]
- intent is to stir discussion on list and possibly address this desire
through mail
>
> 7. Discussion of next F2F place and time
>
- Chris: given previous discussion, seems premature to discuss this
- Hal: does this imply slipping past Q1?
- Chris: would say yes
- Hopes people are coding to v10, to get a head start on things
- Query for who thinks they'd participate
- VeriSign
- MS
- IBM
- BEA
- RSA might
- Sun will depend on timing
- caveat echoed by Oracle, Novell, RSA
- Ron: Sun would prefer not to participate unless they could address
all scenarios
>
> 8. Other business
>
- none
>
> 9. Adjourn
>
- Adjourned
-----------------------------------------------------------------------
Attendance of Voting Members:
Voting Members
First Last Company
Don Adams TIBCO
Zahid Ahmed Commerce One
Steve Anderson OpenNetwork
Paul Cotton Microsoft
William Cox BEA
Peter Dapkus BEA
Martijn de Boer SAP
Thomas DeMartini ContentGuard
Yassir Elley Sun Microsystems
Eric Gravengaard Reactivity
Phil Griffin Griffin Consulting
Frederick Hirsch Nokia
Jeff Hodges Sun Microsystems
Chris Kaler Microsoft
Takashi Kojo NEC
Yutaka Kudo Hitachi
Guillermo Lao ContentGuard
Kelvin Lawrence IBM
Hal Lockhart BEA
Prateek Mishra Netegrity
Ronald Monzillo Sun Microsystems
Tim Moses Entrust
Anthony Nadalin IBM
Nataraj Nagaratnam IBM
Andrew Nash RSA Security
Toshihiro Nishimura Fujitsu
Rob Philpott RSA Security
Hemma Prafullchandra VeriSign
Ed Reed Novell
Irving Reid Baltimore Technologies
Peter Rostin RSA Security
Rich Salz Data Power
Vipin Samar Oracle
Jerry Schwarz Oracle
Senthil Sengodan Nokia
John Shewchuk Microsoft
Frank Seibenlist Argonne National Lab
Steve Trythall Sonic Software
Sam Wei Documentum
John Weiland Navy
Pete Wenzel SeeBeyond
Attendance of Observers or Prospective Members:
TJ Pannu ContentGuard
John Hughes Entegrity
Don Flinn
Monica Martin Drake Certivo, Inc.
Membership Status Changes:
Michael Nguyen Infocomm Dev Authority of Singapore - Requested membership 2/21/2003
John Hughes Entegrity - Requested membership 2/24/2003
TJ Pannu ContentGuard - Granted voting status after 2/25/2003 call
Erick Herring Digital Evolution - Lost voting status due to inactivity
Ron Moritz Computer Associates - Lost voting status due to inactivity
Rob Weltman Netscape/AOL - Lost voting status due to inactivity
--
Steve
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC