[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WS-SX TC Minutes, August 9 2006
WS-SX TC Minutes, August 9 2006 Summary of new Action Items: none 1. Call to order/roll call Present: tbd 2. Reading/Approving minutes of last meeting (August
2) Link Adopted unanimously. 3. TC Logistics (10 minutes or less) Concern over lack of email archives. Chairs indicate that OASIS has said they are
capturing email traffic and will update archives accordingly. Marc Goodner indicated that he may not be able to go
back and retroactively update minutes, issue list when these links become
available. Suggestion to move F2F out several months from
current plan, instead of October suggested first week of December. Will make decision on next TC call. The TC has no conference call hosts beyond next
week. Please contact Kelvin if you can sponsor a call. 4. Interop status There are five companies actively participating. We
have seen interop between 3 companies on 4 of the scenarios, and with the rest
on 2 to 3 of the scenarios. Marc has collected feedback from participants and
will be validating a report on the results soon. After confirmation the results
will be anonymized and reported back to the TC. Note that the interop has been running for some
time, some companies have already announced that they will be ending support
for their endpoints soon. There may still be more companies coming online with
public (as opposed to private) endpoints soon. 5. Issues list http://docs.oasis-open.org/ws-sx/issues/Issues.xml a) Review of action items AI-2006-04-04-08 - Marc Goodner with help from
Prateek Mishra to document interop message flows based on the current version
of SC/Trust. Question to Frederick on his suggested changes 1. Editorial changes, suggest
picking up these changes. 2. SP, need to decide as a TC. 3. Questions, these don’t
prevent work on the other items. Frederick will open issues on the open questions
above. Suggestion to open an issue on SP for interop, hold
for incorporating for next interop round as we are not testing SP in this
round. b) Issues in Review status None. c) New issues i099 - The <IssuedTokens> Element is not used
by WS-SC Accept, assigned Hal as owner. i100 - Lack of Rationale for choices of Authentication
for WS-SC Accept, assigned Hal as owner. i101 - Need additional SamlToken Assertion Elements
for Holder-of-Key and Sender-Vouches Accept. No way to construct type of assertion to represent
token. There is also suggestion to add bearer token, but these should be
handled later. Hadn’t the TC previously decided to leave
specification of XML token assertions to active committees when they still
exist. Not sure that the SAML TC is scoping to handle this. Why isn’t sender vouchers covered by signed
supporting tokens, holder of key would be handled by endorsing. Has not been analyzed. There are many things that tell you enough to
understand which type of SAML assertion you would need. Suggestion that these could be better described in
document. Could be generalized even more, using SAML as an example. General agreement with this suggestion. d) Active issues i004 - Transitive closure spec dependencies In progress. SC recommendations are nearly complete,
should have something back to TC on all specs soon. i008 - Need well formed XML examples Not discussed. i066 - SecurityPolicy use cases Rich Levinson responded to previous comments. Waiting for feedback from commenters before
providing next update. i078 - Specify Reference Types for References to SCT Not discussed, need update from Hal. i081 - Provide policy statements and associated URIs
that can be referenced from wsp:PolicyReference statements Not discussed. i090 - Description of Strict Formatting seems wrong
for EncryptedKey Not discussed, need update from Hal. i094 - We need a definition for "domain"
in WS-SecurityPolicy Hal and Ashook have responded with thoughts on this. Hal does not think RFc term applies. Ashook argues that domain needs to be more granular
within SP, represented by different namespaces. Gudge notes intent of that statement was for policy
authors to use common sense, i.e. don’t nest transaction assertions
inside of security assertions. It was not meant to suggest you could prevent
nonsense assertions. Ashook wants to add focus with additional namespaces,
i.e. message protection and transport protection. Gudge suggests removing statement. Any objections to taking it out? Motion to remove statement, adopted unanimously.
Assigned to editors, status pending. i096 - Ensure Appendix A is complete Not discussed. f) Pending issues Not discussed. i071 - Guidance on Policy Application i074 - Add <EncryptSupportingToken> element to
Sections 7.4 and7.5 i079 - Is Bootstrap policy a PolicyAssertion i080 - Handling EncryptParts specified under
SupportingTokens i082 - Remove duplicate RFC2119 reference i083 - Remove shading from figures, possibly enlarge i084 - Assertions with nested policy do not indicate
it i085 - Replace ID with Id for Id attribute i088 - No XPath default i089 - Minor editorial comments on security policy i091 - security policy help for example C.3.2 i092 - Proposed SP change related to issue 52 i095 - Amend text for nested assertions in WS-SP i097 - No support for message level encryption of
headers for WSS 1.0? i098 - Inconsistencies related to SignedParts/*
assertion 6. AOB Tony is concerned that we have scenarios that don’t
have real usage. We may have to many scenarios. Discussion of scenarios with different token types,
asymettric and symettric keys. There seems to be an inconsistency in the doc,
scenario 2 returns a token that does not seem to be used. That seems
gratuitous. Looking for a subsequent message flow using that
bearer token, as other scenarios do. Question is not about usefulness of bearer token,
the issue is it is not used as it is in other scenarios. The reason this was not done is that bearer tokens
get used in ways that would not be represented here. This scenario should be completed for future interop
events. It is too late for this round to complete this scenario as people are
already beginning to bring down their endpoints. 7. Adjournment The meeting adjourned at 7:53am PST. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]