[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wss] Minutes from F2F #2
Day 1 morning session minutes ... -- Steve -----Original Message----- From: Steve Anderson Sent: Friday, December 13, 2002 4:50 PM To: OASIS WSSTC (E-mail) Subject: [wss] Minutes from F2F #2 The minutes were taken by 4 different individuals, each taking different half-day shifts (starting with me). Since we have a short timeframe before next Tuesday's call, I will post them essentially as-is. Some have summaries, some do not. For those that have summaries, items in those summaries may have been addressed and resolved differently in subsequent sessions. Therefore, I advise reading through these minutes (carefully) in the order posted. Four postings to follow ... -- Steve ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
Minutes for WSSTC F2F, Wednesday 3 December 2002
Dial in info: +1 865 524 4287 #248770.
Minutes taken by Steve Anderson
======================================================================
Summary
======================================================================
Votes:
[NONE - QUORUM NOT REACHED]
New (General) Action Items:
[none]
Issues List Action Items & Status Updates:
- 3
- Ron to write up token labeling proposal, with help from Tony,
BillC, FredH, Don
- 4
- change issue owner to PhillHB
- Chris to write up proposal
- move to pending
- 5
- change issue owner to PhillHB
- Chris to contact PhillHB (done during session)
- PhillHB agrees to link to 5
- move to pending
- 22
- new issue: Kelvin to have document searched for
inconsistencies
- Tony to update definition of claim to be originating from an
"entity", rather than a "client"
- move to close pending vote (CPV)
- 25
- had previously been marked postponed
- 26
- Ron to get with Tony
- 30
- Chris to get with Tony to document XPath-like notation
- move status to postponed to next milestone draft (after
interop draft)
- 31
- move status to postponed to next milestone draft (after
interop draft)
- 38
- move to closed
- 42
- move to closed
- 48
- Kelvin to send email to Zahid to review
- 50
- link to issue 4 & 5
- 51
- Tony to take example out in section 7.1, lines 664-669
- move to CPV
- 52
- Chris to provide more text explaining the preferred
key referencing mechanism in STR section, and send to list
- Profile document editors to define what key names & key
identifiers are with respect to their tokens
- 54
- move to CPV
- 55
- Chris to work with Tony to clarify line 222
- FrederickH to work with Chris/Tony to clarify dynamic XML
schema description
- 56
- Tony to add appendix, and get with Rob to ensure types
are documented
- move to pending
- 57
- closed, withdrawn by Rob
- Chris to provide clarification of use of direct references
vs. key identifiers
- 58
- close, pending Rob's verification
- 61
- FrederickH to get with Tony to integrate his text
======================================================================
Raw Notes
======================================================================
>
> Agenda:
>
> 1. Roll call
>
- Attendance attached to bottom of these minutes
- Quorum NOT achieved yet
>
> 2. Review minutes from previous meeting (12/03)
> < http://lists.oasis-open.org/archives/wss/200212/msg00037.html >
>
- deferred until quorum reached
-
>
> 3. Volunteers for minute takers
>
- Responders
- Steve
- MaryAnn
- Frederick
- Bill Cox
>
> 4. Actions/Issues list
>
- 3: Proposal to Label Tokens to Indicate Their Semantics
- been open for some time
- Tony: proposal on table now is to put label on a STR, rather
than the tokens themselves
- one token may be used for multiple purposes, so labeling it in
a wrapper provides flexibility
- Ron: agrees that use of token has to be labeled
- question of using an attr vs an element to carry the labeling
- also, question of putting multiple labels on a STR
- in the case of a signature, there can be properties, which can
carry labels
- these are usually used in a signature to refer to a key
- [extended discussion]
- mention of SenderVouches from SAML as a use case
- JerryS: describes use case of taking client cert from SSL channel
and pass it on
- but no signature with that cert is possible, because the
intermediary that is passing the cert on doesn't have the private
key
- Hal: solution is to create binary token representation of
that client cert, add it to the message, and add a STR to it
with a label describing it
- Ron: the labeling of the STR does solve a large portion of the
problems, but data references would solve a different set of
problems
- doesn't appear to be possible without breaking DSig
- John: so what do you want to do about trying to add label when
ds:KeyInfo is used (rather than STR)?
- can't label ds:KeyInfo because it's a closed schema
- Chris: ds:KeyInfo has an open content model, but closed attr
model
- so to extend it, an element must be used (rather than an
attr), in which case, you might as well use a STR
- Kelvin: are we getting to a proposal?
- Ron: if you have keyInfo, how do you add label? whatever
solution can be constructed for that will also solve adding a
label to a data reference
- Chris: since an element would have to be used, might as well use
STR
- Ron: doesn't think that use of STR is consistent
- John: looking for specific proposal
- discussion difficult in this setting
- Volunteers to work on a proposal: Ron, Tony, BillC, FredH,
Don
- [ACTION] Ron to write up token labeling proposal, with help
from Tony, BillC, FredH, Don
- Don: this is an important issue for implementors, to clarify
semantic use of tokens
- 4: Why is the token in the header, and not a child of KeyInfo?
- PhilG: wasn't the owner
- Ron: thinks it was PhillHB
- [UPDATE] PhillHB as issue owner
- Chris: background on this
- XMLDsig is fairly closed schema
- bigger driver was that outside of signature, you might want
to use a token
- therefore, need a generic wrapper
- Ron: how do you reconcile case where ds:keyInfo is adequate
- Tony:
- Chris: another goal was to improve interop, but providing a
simpler alternative to ds:keyInfo
- this issue (4) is gating to issue (5)
- Chris: proposes to move this to pending
- [ACTION] Chris to write up proposal
- [UPDATE] move to pending
- 5: Within the KeyInfo, why not use a ds:RetrievalMethod?
- [UPDATE] PhillHB as issue owner
- dependent on issue (5)
- [ACTION] Chris to contact PhillHB
- Hal: not certain that there is a dependency between (4) & (5)
- Hemma: originally, certain token formats were elevated, but
current approach of using token profiles may make this issue moot
- Ron: sees STR as a unification of keyName and retrievalMethod
- unclear whether all cases that keyName covered by STR, and
whether all cases that retrievalMethod covered by STR
- remains open
- 6: Will the authors of the roadmap submit it?
- related to 9
- Kelvin: no news to report
- still looking for a static URL to serve this up
- 9: Approach authors to submit the App Note to the TC
- related to 6
- no news
- 10: Investigate interop fest at some later time
- this is a placeholder for an interop event, which will be driven
by getting out spec to interop draft status
- 19: Core: Why is it necessary to special case a Username/Password
POP token?
- was pending, should be reflected in current doc
- editors have not yet added
- PhilG: aims for early next week, before next call
- 22: Core: Should the spec preclude security tokens whose purpose is
other than to convey or bind a key to an identity or entity?
- was pending
- Tony: proposal is to make this clarification
- if we accept this, Tony can make this change
- Ron: when he raised this question, intent was not to make this
change, was just pointing this out
- Ron: have made some changes to docs to fix this
- discussion of "keys" to mean more than crypto keys, and to
encompass attribute info (a la database keys)
- Hal: so we're not precluding tokens that convey other than
crypto keys, but we are precluding keys that convey other than
attribute info
- Ron: tokens are intended to represent claims, which can be lots
of things
- Ron: proposes we close this issue as to whether or not tokens
are to be used for other than keys, since they are to be used
for claims
- Kelvin: proposes editors search
- [ACTION] new issue: Kelvin to have document searched for
inconsistencies
- [UPDATE] close, pending vote
- Ron: suggests that the "should" part of this issue be dropped
- Hal: believes wording of claim being made by a client is
incorrect
- [ACTION] Tony to update definition of claim to be originating
from an "entity", rather than a "client"
- 25: Core: How can a Signature element occurring outside of the
header be referenced?
- Ron: was his issue
- we postponed this
- 26: Core: What does it mean to process a BinarySecurityToken?
- Ron: hasn't completed this action
- has circled many instances where this phrase is used in the spec
- [ACTION] Ron to get with Tony
- 28: SAML Binding: Include the use of the URI attribute (on
SecurityTokenReference) from the SS TC submission
- Ron: made this change 2 revs ago
- needs Prateek or Don (whoever originally raised the issue) to
review and approve
- Prateek: has not reviewed, will do shortly
- remains pending until Prateek reviews
- [REVISIT]
- 29: SAML Binding: Should there be a reference form that carries what
amounts to a SAML assertion Query such that the sender does not need
to have acquired the assertion (to be able to apply it to a request)?
- Prateek sent mail to list describing usefulness of this
- Kelvin: asks people to review while we're here
- [REVISIT]
- 30: How should XML be explained
- Chris: hasn't seen strong push to change from what we currently
have
- Hal: would at least like a description at the beginning of what
the notation is
- John: proposes, at least for this rev, to not make big change,
and in next draft, incorporate Hal's suggestion of documenting
the notation
- [UPDATE] move status to postponed to next milestone draft (after
interop draft)
- [ACTION] Chris to get with Tony to document notation
- 31: Should use OASIS Namespace
- use the XMLSOAP namespace for now, until OASIS comes to
resolution
- [UPDATE] move status to postponed to next milestone draft (after
interop draft)
- 36: In section 10.2.2, why not just specify that the <Created>
element type be xsd:dateTime?
- [REVISIT]
- 38: line 238: Since this is a normative text, how "inappropriate
claims" is defined here?
- [UPDATE] closed, by virtue of Konstantin's review
- 42: Line 1155: the meaning of "materially" is unclear
- [UPDATE] closed, by virtue of Konstantin's review
- 46: WSDL definitions - It seems to me that a stand-alone
specification should just define the semantics of its elements. If
an application wants those semantics, then the application WSDL
should specify the header as being required.
- John: proposes postponing this until after interop draft
- BillC: concerned that we're pushing too many items out past
interop draft
- not opposing it for this item
- [UPDATE] pending the QoP discussion
- [REVISIT]
- 47:
- [REVISIT]
- 48:
- [REVISIT]
- 49:
- [REVISIT]
- 50:
- Ron: believes defining use cases of STRs would help
- John: we already have an action to go do this
- Ron: suggests leaving this open until those use cases are
produced
- FredH: are the STRs intended to be abstract (meaning, can't be
instantiated, vs. concrete derivations of STRs)
- no
- Chris: should this be marked pending and linked to issue (4)?
- Ron: prefers to keep this open until use cases are available
- [UPDATE] link to issue 4 & 5
[JUMPING BACK]
- 4:
- assuming Chris does write up, this will be closed
- 5:
- Chris spoke with PhillHB, and he believes this is same as (4)
- assuming Chris does write up, this will be closed as well
- 51:
- Chris: we could just take the example out
- [ACTION] Tony to take example out in section 7.1, lines 664-669
- [UPDATE] move to closed (pending vote)
- [REVISIT]
- 52:
- Chris: key identifier is some unique identifier for a token,
which would be defined by the token profile
- example of a hash of a X509 cert
- least explicit reference of a key is key name
- most explicit reference is via direct reference
- key identifier falls somewhere in between
- direct reference is much faster than processing key identifier
- Ron: all for this, it just needs to be spelled out
- Section 7.6 even describes a different type of ambiguity that
can happen
- [ACTION] Chris to provide more text explaining the preferred
key referencing mechanism in STR section
- [ACTION] Chris to send proposed text to list
- [ACTION] Profile document editors to define what key names & key
identifiers are with respect to their tokens
- 53:
- Ron: thought that PhilG's action to move username token text
into its own profile doc obviated this issue
- still open
- 54:
- multiple items in this issue
- first 3 items were pending Don's review
- Don: will review today
- John: Don needs to go thru each item, and will open new issues
for whatever still needs to be addressed
- [UPDATE] move to closed (pending vote)
- 55:
- line 222 is point of contention around encryption
- [ACTION] Chris to work with Tony to clarify line 222
- next sub item: dynamic XML Schema description
- Chris explained intent of this in section 4.2
- FredH: last "may" on line 383 is still confusing
- John: suggests FredH and Chris/Tony work out improved wording
- [ACTION] FredH to work with Chris/Tony to clarify dynamic XML
schema description
- 56:
- John: thought that W3C was working on an ID attribute, to be
added in next ver of SOAP
- so our ID may get replaced in the future
- Hal: what is reason for having two schemas
- Chris: things in utility schema are expected to be used outside
this spec
- Hal: if another group wants to use the utility schema, they won't
want to go through our core doc to find descriptions (where they
are scattered)
- John: proposes putting documentation of utility items into an
appendix, rather than in scattered chapters, with a forward
reference at the beginning
- Tony: counterproposal to maintain readability by keeping the
documentation where it is, and to add an appendix describing
these general utilities, referencing their locations back in the
spec
- Rob: there are some types in the utility schema not documented
in spec, which should be added to appendix
- [ACTION] Tony to add appendix, and get with Rob to ensure types
are documented
- [UPDATE] move to pending
- 57:
- [UPDATE] closed, withdrawn by Rob
- new, related issue raised by Ron
- related to use of direct references vs key identifiers
- [ACTION] Chris to provide clarification of use of direct
references vs. key identifiers
- 58:
- Rob will get with Tony to verify changes are satisfactory
- [UPDATE] close, pending Rob's verification
- [REVISIT]
- 59:
- Guillermo will call Thomas to see if he has verified changes
- [REVISIT]
- 60:
- Guillermo will call Thomas to see if he has verified changes
- [REVISIT]
- 61:
- [ACTION] FredH to get with Tony to integrate his text
- [REVISIT]
[JUMPING BACK]
- 47:
- still pending
- 48:
- Tony: done in latest draft
- awaiting Zahid's review
- [ACTION] Kelvin to send email to Zahid to review
-----------------------------------------------------------------------
Attendance of Voting Members:
Don Adams TIBCO
Steve Anderson OpenNetwork
Paul Cotton Microsoft
William Cox BEA
Martijn de Boer SAP
Yassir Elley Sun Microsystems
Don Flinn Quadrasis
Peter Furniss Choreology
Eric Gravengaard Reactivity
Phil Griffin Griffin Consulting
Frederick Hirsch Nokia
Maryann Hondo IBM
Chris Kaler Microsoft
Yutaka Kudo Hitachi
Guillermo Lao ContentGuard
Kelvin Lawrence IBM
Hal Lockhart Entegrity Solutions
Monica Martin Drake Certivo, Inc.
Prateek Mishra Netegrity
Ronald Monzillo Sun Microsystems
Tim Moses Entrust
Anthony Nadalin IBM
Andrew Nash RSA Security
Toshihiro Nishimura Fujitsu
Mark Nobles LMI
Rob Philpott RSA Security
Hemma Prafullchandra Verisign
Rajesh Raman BEA Systems
Jerry Schwarz Oracle
Shawn Sharp Cyclone Commerce
John Shewchuk Microsoft
Frank Siebenlist Argonne National Lab
Gene Thurston AmberPoint
John Weiland Navy
Attendance of Observers or Prospective Members:
Lloyd Burch Novell
Eric Cohen PwC
Membership Status Changes:
Joel Munter Intel - Withdrew 12/4/2002
Jeremy Epstein webMethods - Withdrew 12/8/2002
Hank Simon Lockheed Martin - Withdrew 12/9/2002
Takashi Kojo NEC - Withdrew 12/9/2002
Greg Carpenter Nokia - Withdrew 12/10/2002
Simon Godik Overxeer - Withdrew 12/11/2002
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC