[VER 2] WS-SX TC Minutes, June 21 2006

["Marc Goodner" <mgoodner@microsoft.com>]

[VER 2] Added roll call.

WS-SX TC Minutes, June 21 2006

We are grateful to Oracle for sponsoring this call.

Summary of new Action Items:
AI-2006-06-21-01 Frederick to work on a new proposal for issue 70.

1. Call to order/roll call
    
Present:
Jong Lee, BEA Systems, Inc.* 
Hal Lockhart, BEA Systems, Inc.* 
Denis Pilipchuk, BEA Systems, Inc.* 
Corinna Witt, BEA Systems, Inc.* 
Yakov Sverdlov, CA* 
Toshihiro Nishimura, Fujitsu Limited* 
Irving Reid, Hewlett-Packard* 
Greg Whitehead, Hewlett-Packard* 
Ching-Yun (C.Y.) Chao, IBM* 
Henry (Hyenvui) Chung, IBM* 
Anthony Nadalin, IBM* 
Ron Williams, IBM* 
Mike Lyons, Layer 7 Technologies Inc.* 
Jan Alexander, Microsoft Corporation* 
Paul Cotton, Microsoft Corporation* 
Colleen Evans, Microsoft Corporation* 
Mark Fussell, Microsoft Corporation* 
Marc Goodner, Microsoft Corporation* 
Martin Gudgin, Microsoft Corporation* 
Chris Kaler, Microsoft Corporation* 
Asir Vedamuthu, Microsoft Corporation* 
Norman Brickman, Mitre Corporation* 
Frederick Hirsch, Nokia Corporation* 
Abbie Barbir, Nortel Networks Limited* 
Lloyd Burch, Novell* 
Steve Carter, Novell* 
Ashok Malhotra, Oracle Corporation* 
Prateek Mishra, Oracle Corporation* 
Alex Hristov, Otecia Incorporated* 
John Hughes*, PA Consulting* 
Martin Raepple, SAP AG* 
Jiandong Guo, Sun Microsystems* 
Don Adams, Tibco Software Inc.* 
Ruchith Fernando, WSO2*

Status changes 
Lost the following voting members:
Mike McIntosh, IBM

2. Reading/Approving minutes of last meeting (June 14)
http://lists.oasis-open.org/archives/ws-sx/200606/msg00043.html
Adopted unanimously.

3. TC Logistics (10 minutes or less)

4. Issues list
http://docs.oasis-open.org/ws-sx/issues/Issues.xml
    
a) Review of action items
AI-2006-04-04-03 - Tony Nadalin to identify possible issues for
SecurityPolicy based on the changes proposed for Issue 52.
Have not found any, will probably ask to close this later this week.

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.
Expect an update before next weeks call.

AI-2006-05-03-03 - Tony will investigate and start thread on issue 67.
Needs more time.


b) Issues in Review status
Please review resolution for issues below in latest drafts before next
week's call.

i031 - Clarification for UsernameToken assertion
http://lists.oasis-open.org/archives/ws-sx/200606/msg00048.html
Does not make it clear that nonce and timestamp are not included.
Prateek will look at this in the updated spec and open a new issue.

i033 - Identify security header components that are signed and/or
encrypted

i048 - Binding Assertions should support Operation subjects

i057 - Final protocol message should always be an RSTRC
http://lists.oasis-open.org/archives/ws-sx/200606/msg00049.html
Has been fixed but not posted yet, will wait until next update

i065 - Permitting requestors to avoid recieving cancel messages

i069 - Default assertions and policy intersections

i072 - Missing KeyWrapAlgorithm requirement in section 9.2

i073 - Key and Encryption Requirements Clarification

i075 - HTTP Auth Subassertions

   
c) New issues
i076 - How to reference a specific SC when initiating a session?
Accepted, assigned Prateek as owner.
Active discussion on list already

Question on whether or not this is addressed already. 
http://lists.oasis-open.org/archives/ws-sx/200606/msg00047.html
Prateek to investigate.

d) Active issues

i004 - Transitive closure spec dependencies

i008 - Need well formed XML examples
Not looking for more examples, just need to validate well formed-ness.
Significant amount of work required as examples need to be pulled out
into separate documents, no estimate yet.

i066 - SecurityPolicy use cases
Proposal 1
http://lists.oasis-open.org/archives/ws-sx/200606/msg00025.html
People need more time, discuss next week.

i067 - Resolving Policies if more than one SecureConversationToken is
present
AI-2006-05-03-03

i070 - Clarify relationship between extensibility model and policy
intersection Has been some discussion on the list.
Prateek thinks this should be closed.
Frederick disagrees, he thinks there is an issue here.
[Discussion notes - please continue discussion on the list] Policy
defines set of matching rules, so you should not get to many false
positives even if there is no knowledge of the domain specific
assertions.
Service provider offers any username token, client says uses username
1.1, would that match?
See example here:
http://lists.oasis-open.org/archives/ws-sx/200606/msg00034.html
Somehow the provider needs to advertise all options they support.

Discussion of what it means to match all or none of the nested
assertions, some disagreements in this area Ennumeration of all options
can be defined once and referenced Anyone can invent and modify the
assertions, you can't say you support all subassertions as there may be
ones defined that you are unaware of What about putting the extensions
in a well known place so it could be walked down and determined if you
really understand all?
Suggestion that text needs to say something about needing to ennumerate
all possible options Some people uncomfortable with ennumerating in
place There is the alternative is to put it in one place and reference
it

AI-2006-06-21-01 Frederick to work on a new proposal for issue 70.
Goal of this is to understand and address concerns that have been raised
in today's discussion Please continue discusion on list.

i071 - Guidance on Policy Application
Revised proposal
http://lists.oasis-open.org/archives/ws-sx/200606/msg00036.html
Change "for example because a client certificate has expired" to "for
example because a client certificate has been revoked"
Revised proposal above accepted, status changed to pending.

i074 - Add <EncryptSupportingToken> element to Sections 7.4 and7.5
Revised proposal
http://lists.oasis-open.org/archives/ws-sx/200606/msg00021.html
Note, summary list at top does not match specfic text - this addressed
the only concern expressed on the call (the specific text is right) Did
not propose encrypted suporting, not seen as useful Revised proposal
above accepted, status changed to pending.

Concern over figure at sec 8.4 line 2119 Shouldn't sig 2 is not covered
by sig 1 - needs to be blue line No, there isn't an error in the
diagram, it's the token that is signed by the message signature not the
signature generated by the token (Gudge and Frederick both agreed the
figure is correct by end of the
call)

f) Pending issues

  None.


5. AOB

None.

6. Adjournment

The meeting adjourned at 10:55