WS-SX TC Minutes, June 21 2006

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

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:
tbd

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