[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [VER 4] WS-SX TC F2F Minutes, Austin, TX, Apr 4-5 2006
WS-SX TC F2F Minutes, Austin, TX, Apr 4-5 2006
[VER 4] Added Richard Levinson to roll call.
[VER 3] Added roll call information provided by Abbie.
Summary of new F2F Action items:
AI-2006-04-04-01 - Chris Kaler to provide advice on minimum acceptable lengths of P-SHA1 inputs for Issue 20.
AI-2006-04-04-02 - Frederick to revise wording for Rule 5 re use of multiple signatures for Issue 52.
DONE. See:
http://lists.oasis-open.org/archives/ws-sx/200604/msg00033.html
AI-2006-04-04-03 - Tony Nadalin to identify possible issues for SecurityPolicy based on the changes proposed for Issue 52.
AI-2006-04-04-04 - Jan Alexander and Martin Gudgin to identify possible issues for SecurityPolicy based on creation of the NoProofKey proposed in the solution to Issue 56.
AI-2006-04-04-05 - Jan Alexander and Tony Nadalin to identify possible issues for WS-Trust's processing model for the changes made for Issue 57.
AI-2006-04-04-06 - Jan Alexander to start a discussion about security considerations and a section about what this means for relying parties re the proposal adopted for Issue 060.
AI-2006-04-04-07 - Marc Goodner with help from Prateek Mishra to create a merged interop scenarios document.
AI-2006-04-04-08 - Marc Goodner with help from Prateek Mishra to document interop message flows based on a future revised version of SC/Trust.
AI-2006-04-04-09 - Chairs to check with absent companies on their plans for SC/Trust interop.
AI-2006-04-05-01 - Tony Gullotta will start an email discussion about issue 31 and whether it should be broadened to include other token characteristics.
AI-2006-04-05-02 Gudge to propose revised text for the description of sp:BootstrapPolicy for issue 53.
AI-2006-04-05-03 - Tony N and Frederick to consider adding batch facilities to SecureConversation as per Issue 64.
AI-2006-04-05-04 Chairs to do further work on a F2F meeting time and location.
1. Call to order/roll call
Present:
Hal Lockhart, BEA Systems, Inc.*
Denis Pilipchuk, BEA Systems, Inc.*
Symon Chang, Blue Titan Software*
Richard Levinson, CA*
Toshihiro Nishimura, Fujitsu Limited*
Greg Whitehead, Hewlett-Packard*
Ching-Yun (C.Y.) Chao, IBM*
Henry (Hyenvui) Chung, IBM*
Heather Hinton, IBM*
Kelvin Lawrence, IBM*
Michael McIntosh, IBM*
Anthony Nadalin, IBM*
Jan Alexander, Microsoft Corporation*
Paul Cotton, Microsoft Corporation*
Colleen Evans, Microsoft Corporation*
Vijay Gajjala, Microsoft Corporation*
Marc Goodner, Microsoft Corporation*
Martin Gudgin, Microsoft Corporation*
Chris Kaler, Microsoft Corporation*
Jonathan Marsh, Microsoft Corporation*
Jeff Hodges, Neustar, Inc.*
Frederick Hirsch, Nokia Corporation*
Abbie Barbir, Nortel Networks Limited*
Paul Knight, Nortel Networks Limited*
Ashok Malhotra, Oracle Corporation*
jeff mischkinsky, Oracle Corporation*
Prateek Mishra, Oracle Corporation*
Alex Hristov, Otecia Incorporated*
John Hughes*, PA Consulting*
Tony Gullotta, SOA Software Inc.*
Don Adams, Tibco Software Inc.*
2. Reading/Approving minutes of last meeting (Mar 29)
http://lists.oasis-open.org/archives/ws-sx/200603/msg00110.html
Adopted unanimously.
3. F2F agenda information:
http://lists.oasis-open.org/archives/ws-sx/200604/msg00014.html
4. Issues list
http://docs.oasis-open.org/ws-sx/issues/Issues.xml
a) Review of action items
ai-09 - Editors to check that XPath examples in WS-SecurityPolicy are fully namespace qualified.
See: http://lists.oasis-open.org/archives/ws-sx/200603/msg00093.html
The F2F meeting decided that this matter was closed since no problems in the XPath examples could be identifier.
AI-2006-02-15-04 - Prateek to propose resolution to Issue 20 before F2F
DONE. See:
http://lists.oasis-open.org/archives/ws-sx/200604/msg00024.html
AI-2006-02-15-07 - TC members to come to the April F2F with data on when they would be ready to carry out SC/Trust interop.
Considered DONE since it is on the F2F agenda.
ACTION 2006-03-08-02 Mike to provide better description(s) and a
complete proposal(s) for issue 016 and issue 018 by the F2F meeting.
DONE. See:
http://lists.oasis-open.org/archives/ws-sx/200603/msg00103.html
http://lists.oasis-open.org/archives/ws-sx/200603/msg00104.html
AI-2006-03-15-01 - Gudge and Prateek to draft a new section "Guidance on creating New Token Assertions and Token Assertion Extensibility" for review by the TC (for issue 30).
Pending.
AI-2006-03-22-01 - Tony Nadalin to provide information on where the UML generated schema might be more restrictive than the SP schema.
See below. Closed.
AI-2006-03-22-02 - Prateek Mishra to expand his additional scenarios to define the message RSTR's for the Bearer Assertion and HoK Assertions and to show where they are actually different.
DONE. See:
http://lists.oasis-open.org/archives/ws-sx/200604/msg00025.html
AI-2006-03-29-01 - Gudge owes Prateek a response (to message 82) for issue 33.
Pending.
AI-2006-03-29-02 - Tony Gullota to provide further examples illustrating issue 48 in time for the F2F.
DONE. See:
http://lists.oasis-open.org/archives/ws-sx/200603/msg00122.html
AI-2006-03-29-03 - Martin Raepple will provide text for new section from issue 41 before the F2F.
DONE. See:
http://lists.oasis-open.org/archives/ws-sx/200603/msg00115.html
AI-2006-03-29-04 - Marc Goodner to update interop doc with resolution of issue 47 before F2F.
Pending.
b) Issues in Review status
i003 Use of term "binding" in specs
i009 Support for different key pairs for sign and encrypt in SP
i010 Proof of possesion for security intermediaries
i023 Properties for Algorithm Suite missing or wrong
i025 Chap. 6.5 [Token protection] conflicts with chapter 8.3 and 8.4
i026 Chapter 6.7 [Security Header Layout]
i027 When to include a token?
i029 Which token to use to encrypt/sign in case of multiple tokens defined in a supporting token assertion?
i032 WS-SP should permit Policy to specify the use of keys derived from passwords
i034 Editorial comments on WS-Trust
i036 Clarify term pre-authentication
i037 Add element extensibility to RequestSecurityTokenResponseCollection/IssuedTokens
i038 Clarify that ComputedKey optional
i040 What values can be carried in a /wst:RequestSecurityToken/wst:Claims element?
i045 Duplicate Id attribute values in Security Context example
i049 Clarify that [Algorithm Suite] applies to message level cryptography and NOT transport-level cryptography
i050 Clarify scope of Protection assertions
TC agreed to add review at the F2F meeting.
Change status of ALL the above issues to CLOSED.
c) New issues
i052 Add single request for multiple tokens
http://lists.oasis-open.org/archives/ws-sx/200603/msg00113.html
i053 Message parts to be protected using BootstrapPolicy
http://lists.oasis-open.org/archives/ws-sx/200603/msg00119.html
i054 Clarification on Signature Protection property and various SupportingTokens
http://lists.oasis-open.org/archives/ws-sx/200603/msg00120.html
i055 Clarification on RequireDerivedKeys and X509Token under
AsymmetricBinding
http://lists.oasis-open.org/archives/ws-sx/200603/msg00121.html
i056 Add new Bearer Token KeyType
http://lists.oasis-open.org/archives/ws-sx/200604/msg00016.html
i057 Final protocol message should always be an RSTRC
http://lists.oasis-open.org/archives/ws-sx/200604/msg00017.html
i058 Validate binding should have a ValidateTarget
http://lists.oasis-open.org/archives/ws-sx/200604/msg00018.html
i059 Final protocol message should have a distinct action
http://lists.oasis-open.org/archives/ws-sx/200604/msg00019.html
i060 New binding for STS starting the token cancellation process
http://lists.oasis-open.org/archives/ws-sx/200604/msg00020.html
i061 Add wsc:Length attribute to the Implied derived key
http://lists.oasis-open.org/archives/ws-sx/200604/msg00021.html
The above issues were accepted as issues and will be marked as ACTIVE. These are processed in item d) below.
Error in the WS-SecurityPolicy Schema
http://lists.oasis-open.org/archives/ws-sx/200603/msg00128.html
Created to be Issue 63:
http://lists.oasis-open.org/archives/ws-sx/200604/msg00023.html
Change status to Active. Assigned to Editors.
d) Active issues
i004 Paul Cotton Transitive closure spec dependencies
Pending.
i008 Editors Need well formed XML examples
Pending. Should be done by the F2F.
i020 Describe minimum acceptable lengths for P_SHA1 inputs
AI-2006-02-15-04 - Prateek to propose resolution to Issue 20 before F2F
DONE. See:
http://lists.oasis-open.org/archives/ws-sx/200604/msg00024.html
AI-2006-04-04-01 - Chris Kaler to provide advise on minimum acceptable lengths of P-SHA1 inputs for Issue 20.
i044 What is an authorization token?
http://lists.oasis-open.org/archives/ws-sx/200603/msg00030.html
See Tony's message:
http://lists.oasis-open.org/archives/ws-sx/200603/msg00102.html
Authorization Token - Security token indicating a claimaint's entitlement.
The original issue was about the following text:
WS-Trust line 1185:
"In other cases an authorization token MAY be returned."
Proposed replacement text:
"In other cases a security token MAY be returned and used for authorization."
WS-Trust Line 839:
"In this example a supporting authorization token is returned that has no separate proof-of-possession token as it is secured using the same proof-of-possession token that was returned."
Proposed replacement text:
"In this example a supporting security token is returned that has no separate proof-of-possession token as it is secured using the same proof-of-possession token that was returned."
The above two changes were adopted unanimously. Change status to Pending. Assigned to Editors.
i052 Add single request for multiple tokens
http://lists.oasis-open.org/archives/ws-sx/200603/msg00113.html
The proposal in PDF format is attached to:
http://lists.oasis-open.org/archives/ws-sx/200603/msg00112.html
Frederick is trying to solve the problem of obtaining more than one token in a single round trip. The proposal tries to recognize the problems previously noted on adding a generalized batch mechanism.
Tony started by saying that he agrees with the concept. Then we dealt with Tony's specific comments
a) Looking at the processing rule 5.a):
"No negotiation or other multi-leg authentication mechanisms are allowed
when a batch request is used; the communication with STS is limited to
one batched-RST request and one RSTRC response."
What does the receiver do if this happens? Hal suggested a general rule that "The recipient should generate a fault if the requestor violates any of the following processing rules." Add this at the beginning of the proposed section 4.2.1.
b) Lack of symmetry
4.2.1 Processing Rules
1. The RequestMultipleSecurityTokens (RMST) element contains 2 or more
RequestSecurityToken elements.
Proposal: Remove rule 1 above and add the following text at a location to be determined:
"A Requestor must be able to receive multiple tokens. A Recipient does not have to accept multiple batch requests"
c) Rule 2 text:
" The single RequestSecurityTokenResponseCollection response MUST contain at
least one RSTR element corresponding to each RST element in the request. A RSTR element corresponds to an RST element if it has the same Context attribute value as the RST element."
Tony noted that there could be more than one RSTR with the same Context attribute element.
Proposed new text: "Note: Each request may generate more than one RSTR sharing the same Context attribute value".
d) Rule 4 text:
"Every RST in the request MUST use an action URI value ..."
Proposal: Change the above text to:
"The request MUST use an action URI value ..."
e) Add additional rule 4' that follows the existing rule 4:
"Every RST in the request must have the same request type (which must correspond to the request action URI)."
f) The example in 4.2 has no URI action and has the wrong request types on lines 27 and 41.
g) Heather asked if we were going to nest the collections. Several TC members said that the correspondence is determined by the Context attribute.
No change required.
h) Rule 5 states:
"Thus a single Signature referencing the RSTR in the batch request would be appropriate."
Chris Kaler explained that this text meant the following:
a) you have as many signatures as you want
b) but all the signatures used must apply to the entire batch request.
AI-2006-04-04-02 - Frederick to revise wording for Rule 5 re use of multiple signatures for Issue 52.
DONE. See:
http://lists.oasis-open.org/archives/ws-sx/200604/msg00033.html
Change #5 from
" A single authentication mechanism MUST be used for every
requested security token in a single message when batch request is
used. Thus a single Signature referencing the RSTR in the batch
request would be appropriate"
to
"All Signatures MUST reference the entire RSTC. One or more Signatures referencing the entire collection MAY be used."
Note this change was adopted on Wed Apr 5.
j) Rule 6:
" 6. This mechanism requires that every RST in a RMST is to be handled by the single endpoint processing the RMST."
Proposal:
Delete Rule 6.
k) Section 4.3 states:
"Every RSTR MUST have a Context attribute with the value given in the corresponding RST element.
Proposal:
Delete this paragraph since it is redundant give Rule 3 in Section 4.2.1.
l) Global change:
Change RequestMultipleSecuityTokens (RMST) to RequestSecurityTokenCollection (RSTC) throughout the proposal.
m) Section 4.3 states:
"If an error occurs in the processing of a single request, a SOAP Fault MUST be generated for the entire batch request, so no RSTR elements will be returned in this case."
Proposal: Change the above text to:
"If any error occurs in the processing of the RSTC or one of its contained RSTs, a SOAP fault must be generated for the entire batch request so no RSTC element will be returned."
n) Hal requested we drop of the reference to the Security Roadmap document.
The Editors should check the examples when implementing the revised proposal.
o) Rule 5 a) states:
"No negotiation or other multi-leg authentication mechanisms are allowed
when a batch request is used; the communication with STS is limited to
one batched-RST request and one RSTRC response."
Proposal: Change the above to:
"No negotiation or other multi-leg authentication mechanisms are allowed
in batch requests or responses to batch requests; the communication with STS is limited to one batched-RST request and one RSTRC response."
The proposal as revised by the above amendments was adopted unanimously.
Change status of Issue 52 to Pending. Assigned to Editors.
AI-2006-04-04-03 - Tony Nadalin to identify possible issues for SecurityPolicy based on the changes proposed for Issue 52.
New Issue 64: Should SecureConversation support batch semantics as created by Issue 52.
Change status of new Issue 64 to Active. Initial Owner to be Tony N. Marc will send an initiating email for this issue. Done. See:
http://lists.oasis-open.org/archives/ws-sx/200604/msg00029.html
AI-2006-04-05-03 - Tony N and Frederick to consider adding batch facilities to SecureConversation as per Issue 64.
i056 Add new Bearer Token KeyType
http://lists.oasis-open.org/archives/ws-sx/200604/msg00016.html
Revised proposal:
Add the following into the table after line 1779:
http://docs.oasis-open.org/ws-sx/wstrust/200512/Bearer
A bearer token is requested. This key type can be used by requestors to indicate that they want a security token to be issued that does not require proof of possession.
Adopted unanimously.
Change status of Issue 56 to Pending. Assigned to Editors.
AI-2006-04-04-04 - Jan Alexander and Martin Gudgin to identify possible issues for SecurityPolicy based on creation of the NoProofKey proposed in the solution to Issue 56.
i057 Final protocol message should always be an RSTRC
http://lists.oasis-open.org/archives/ws-sx/200604/msg00017.html
Proposal:
Change the specification so that the issued token(s) can be returned
using RSTRC only. If intermediary messages are necessary either RSTR or
RSTRC can be used for those intermediary messages.
Section 3.2 needs to be reworded to explain this change including the examples.
Section 4.3 can be removed.
All other section need to be updated to use RSTRC instead of RSTR when
talking about final response messages.
Add the following additional text:
"Security tokens can only be returned in the RSTRC on the final leg."
Adopted unanimously. Change status to Pending. Assigned to Editors.
AI-2006-04-04-05 - Jan Alexander and Tony Nadalin to identify possible issues for WS-Trust's processing model for the changes made for Issue 57.
i058 Validate binding should have a ValidateTarget
http://lists.oasis-open.org/archives/ws-sx/200604/msg00018.html
Proposed Resolution:
Add <wst:ValidateTarget>...</wst:ValidateTarget> to the XML outline
after WS-Trust line 1202.
Add following before line 1215:
/wst:RequestSecurityToken/wst:ValidateTarget
This required element identifies the token being validated. Typically
this contains a <wsse:SecurityTokenReference> pointing at the token, but
could also carry the token directly.
Adopted unanimously. Change status to Pending. Assigned to Editors.
i059 Final protocol message should have a distinct action
http://lists.oasis-open.org/archives/ws-sx/200604/msg00019.html
Proposed Resolution:
Sections 4, 5, 6, 7, and 10 need to be updated to add a new
WS-Addressing action for the final message.
The proposed actions for the final messages are:
Issuance binding:
http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal
Renewal binding:
http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/RenewFinal
Cancel binding:
http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/CancelFinal
Validation binding:
http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/ValidateFinal
Key Exchange Token Binding:
http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/KETFinal
Note that this impacts the WS-Trust WSDL.
Adopted unanimously. Change status to Pending. Assigned to Editors.
i060 New binding for STS starting the token cancellation process
http://lists.oasis-open.org/archives/ws-sx/200604/msg00020.html
The detailed proposal is attached to:
http://lists.oasis-open.org/archives/ws-sx/200604/msg00009.html
Adopted unanimously. Change status to Pending. Assigned to Editors.
AI-2006-04-04-06 - Jan Alexander to start a discussion about security considerations and a section about what this means for relying parties re the proposal adopted for Issue 060.
Create a new issue (Issue 65) Permitting Requesters to avoid receiving Cancel messages. Assigned to Tony Nadalin and Jan Alexander.
i061 Add wsc:Length attribute to the Implied derived key
http://lists.oasis-open.org/archives/ws-sx/200604/msg00021.html
Change proposal to SecureConversation:
Add the following text after line 883:
The @wsc:Length attribute can be used in conjunction with @wsc:Nonce in
the security token reference (STR) to indicate the length of the derived
key. The value of this attribute is an unsigned long value indicating
the size of the key in bytes. If this attribute isn't specified, the
default derived key length value is 32.
Adopted unanimously. Change status to Pending. Assigned to Editors.
e) SecurityPolicy Active issues (to be processed on Apr 5)
i016 Michael McIntosh sp:SignedParts mechanism
ACTION 2006-03-08-02 Mike to provide better description(s) and a
complete proposal(s) for issue 016 and issue 017 by the F2F meeting.
DONE. See:
http://lists.oasis-open.org/archives/ws-sx/200603/msg00103.html
Adopted unanimously. Change status to Pending. Assigned to Editors.
Several anonymous TC members suggested that we should look at specifying security policies for intermediaries.
i018 Michael McIntosh absolute XPath expressions
ACTION 2006-03-08-02 Mike to provide better description(s) and a
complete proposal(s) for issue 016 and issue 017 by the F2F meeting.
DONE. See:
http://lists.oasis-open.org/archives/ws-sx/200603/msg00104.html
Paul Cotton suggested we add a reference to "absolute location path" in the XPath 1.0 spec. See:
http://www.w3.org/TR/1999/REC-xpath-19991116#NT-AbsoluteLocationPath
Paul indicated that no such reference appears to be available for XPath 2.0 but the concept is obviously still supported.
Adopted unanimously. Change status to Pending. Assigned to Editors.
i028 Werner Dittmann Multiple supporting tokens of the same type?
See: http://lists.oasis-open.org/archives/ws-sx/200603/msg00079.html
The original question in the issue is the following:
"Can a Policy have more than one supporting token (of the same type), e.g. multiple SupportingTokens or multiple EndorsingSupportingTokens?"
The TC agreed that the answer to this question is yes.
Adopted unanimously. Change status to Closed.
AI-2006-03-22-01 - Tony Nadalin to provide information on where the UML generated schema might be more restrictive than the SP schema.
Closed.
Tony offered to do a point in time analysis but the SP schema needs to be updated. Hal asked if a generic description of the possible restrictions might be supplied.
Hal noted that he felt that the UML information was very useful. Hal would be in favour of keeping the UML document "on the side". Other members suggested that we could decide to update this later when SP has made more progress.
The TC agreed to terminate this action item and agreed to open an issue and defer the issue for this work (Issue 62). This work will be picked up again when the UML model and schema is re-generated from a future more stable version of SP.
i030 Need a mechanism to identify token assertions
Should be covered by Gudge and Prateek's action item:
AI-2006-03-15-01 - Gudge and Prateek to draft a new section "Guidance on creating New Token Assertions and Token Assertion Extensibility" for review by the TC (for issue 30).
Gudge posted a late proposal in:
http://lists.oasis-open.org/archives/ws-sx/200604/msg00030.html
Gudge indicated that Werner had previously agreed that Issue 30 could be resolved by the text that was expected as per this action item.
Adopted unanimously as a resolution to Issue 30. Change status to Pending. Assigned to Editors.
i031 Clarification for UsernameToken assertion
Previously the TC left this issue pending on Issue 30.
Gudge noted that he believed that the text adopted for Issue 30 covered this issue.
AI-2006-04-05-01 - Tony Gullotta will start an email discussion about issue 31 and whether it should be broadened to include other token characteristics.
i033 Identify security header components that are encrypted
No discussion by email has occurred since last week's meeting.
AI-2006-03-29-01 Gudge owes Prateek a response (to message 82) for issue 33.
Unlikely to be done before F2F.
Status: Pending. Revised ETA is now Mon Apr 10.
i048 Binding Assertions should support Operation subjects
AI-2006-03-29-02 Tony Gullotta to provide further examples illustrating issue 48 in time for the F2F.
http://lists.oasis-open.org/archives/ws-sx/200603/msg00085.html
Tony Gullotta's most recent proposal:
http://lists.oasis-open.org/archives/ws-sx/200603/msg00065.html
There was some agreement to the following change to the proposal:
"This assertion MUST apply to [Endpoint Policy Subject]. This assertion MAY apply to [Operation Policy Subject]."
But it was pointed that we have define the "merge semantics" e.g. pick the "operation policy subject" assertion. The PolicyAttachment spec tells you to merge the policies from the Endpoint and Operations. Gudge said that he was not sure how to write these rules since after the PolicyAttachment merge it is not obvious which assertion came from which location.
Gudge and Hal pointed out that the Protection Assertion merging works since it does not depend on the "level of attachment".
Tony Gullotta suggested an alternative to avoid the need for merge semantics enforce the rule that if you do it at the operation level you cannot do it at the Endpoint level and insist that it is defined for all operations.
The choices appears to be:
a) we allow the assertions to appear at multiple locations and we need to define the merge semantics
b) we avoid the need for merge semantics by limiting where the assertions can occur (see above Tony G proposal).
Note that the current SP document limits the assertions to Endpoints and thus no merge semantics are required.
We left this issue open for future email discussion.
i051 sp:RequireDerivedKeys is underspecified
http://lists.oasis-open.org/archives/ws-sx/200603/msg00100.html
Adopted unanimously. Change status to Pending. Assigned to Editors.
i053 Message parts to be protected using BootstrapPolicy
http://lists.oasis-open.org/archives/ws-sx/200603/msg00119.html
"How are the Signed(Parts/Elements)/Encrypted(Parts/Elements)that are to
be secured using the Bootstrap policy obtained. Are they implicit?"
BootstrapPolicy applies to the RST/RSTR and is a separate policy. It can contain any assertions from SP and these are what apply. See lines 1101-1103 (/SP:SecureconvsersationToken/wsp:Policy/sp:BootstrapPolicy).
Hal pointed out that the text on line 1105 might be incorrect:
"This element contains the security binding requirements for obtaining the Security Context Token." The example below this might also need for "..." text to indicate other assertions are possible.
AI-2006-04-05-02 Gudge to propose revised text for the description of sp:BootstrapPolicy for issue 53.
i054 Clarification on Signature Protection property and various SupportingTokens
http://lists.oasis-open.org/archives/ws-sx/200603/msg00120.html
Gudge's reply answers the questions:
http://lists.oasis-open.org/archives/ws-sx/200604/msg00015.html
Q1: Gudge's reply:
"[Signature Protection] is about encrypting a ds:Signature element only
applies to the primary signature. [Token Protection] is about signing a security token ( e.g.saml:Assertion, wsse:BinarySecurityToken etc. )."
Q2: Gudge's reply:
"From Section 6.4; If the value is 'true', the primary signature MUST be encrypted and any signature confirmation elements MUST also be encrypted.
Section 8.5 Interaction between [Token Protection] property and supporting token assertions discusses it's relationship with supporting token assertions."
Change status to Closed with no changes.
i055 Clarification on RequireDerivedKeys and X509Token under
AsymmetricBinding
http://lists.oasis-open.org/archives/ws-sx/200603/msg00121.html
The TC discussed this issue but it was not clear what use the case that K. Venugopal was discussing. The TC would like him to better explain his use case so that we can understand the issue.
Paul C sent email to K. Venugopal to ask him to clarify his use case.
i063 Error in the WS-SecurityPolicy Schema
http://lists.oasis-open.org/archives/ws-sx/200603/msg00128.html
Created to be Issue 63:
http://lists.oasis-open.org/archives/ws-sx/200604/msg00023.html
Assigned to Editors during New Issues discussion above.
Change status to Pending.
AI-2006-04-05-03 Editors to evaluate the proposal in the Issue 63 proposal to change the "namespace prefix of tns to sp" throughout the document.
New item: Comments on Security Policy and a Suggestion, Ashok Malhotra
http://lists.oasis-open.org/archives/ws-sx/200604/msg00031.html
Ashok introduced his desire to have some typical use cases to demonstrate how SP can be used. Hal agreed with the proposed effort and said BEA would participate. Chris Kaler wondered whether there can be "an agreed upon set of scenarios".
Hal suggested we do some initial work by email. Chris replied that asking questions about using SP would definitely be in scope. Tony N said that IBM had analyzed the WS-I BSP Sample Applications and believed that SP could handle all those WSS use cases. Paul suggested that we also consider the WS-I BSP Scenarios document.
Tony suggested that the TC needs to get SC/Trust really solid and in Committee Draft form before we do this kind of work on SP. Some members agreed and some disagreed. Hal offered to provide some use cases for this work.
The TC agreed to open an new SP issue (Issue 66: Security Policy Use Cases) based on Ashok's request. Ashok is the initial owner. Hal and Tony agreed to see if they could make some initial contributions to this new issue.
f) Pending Issues
i041 Clarification on token propagation of SCT required ws-sc design
AI-2006-03-29-03 Martin Raepple will provide text for new section from issue 41 before the F2F.
DONE. See:
http://lists.oasis-open.org/archives/ws-sx/200603/msg00115.html
Proposed by Jan:
Remove the following two sentences from the proposal:
"There are scenarios where a dedicated security token service is used to broker trust between multiple requesters and Web Services endpoints. In these cases the security token service must propagate the SCT and the proof information to the requester and the endpoint(s)."
Change the following sentence:
If the security token service has no prior knowledge of which parties the requester needs a token for, it is RECOMMENDED that the requester provides this information to the security token service using the optional element <wsp:AppliesTo> with an endpoint reference as described in [WS-Trust] in the SCT request.
to the following:
If the Requestor needs to communicate the identification of the service for which the SCT be issued by the STS, it is RECOMMENDED that the requester needs to communicate information about the service provides this information to the security token service using the optional element <wsp:AppliesTo> with an endpoint reference as described in [WS-Trust] in the SCT request.
The revised proposal was adopted and the Editors should apply this revised change.
i043 Missing enumeration for validate request type in the RequestTypeEnumdefinition
Pending work on schemas.
i047 Does IssuedTokenOverTransport require client-side digital signature?
AI-2006-03-29-04 Marc Goodner to update interop doc with resolution of issue 47 before F2F.
5. Interop scenarios
a) Broad approach to interop
Prateek asked what our broad approach is to interop.
Kelvin suggested that we follow the WSS model. That is, someone volunteers to act as Editor of an scenarios document, companies volunteer to participate in an interop event, we schedule and carryout the interop, and we determine if there are issues arising from the interop success/failure.
Tony believes the goal should be test on the wire messages.
Hal believes the interop's goal should be to test if multiple parties have the same interpretation of the spec and to "debug" the spec.
Chris suggested that we are not looking for full N by N feature testing and we will have to decide if scenarios are similar enough to be considered to be duplicates.
b) Additional SC/Trust scenarios, Prateek
http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/17530/ws-sx-additional-interop-01.doc
AI-2006-03-22-02 - Prateek Mishra to expand his additional scenarios to define the message RSTR's for the Bearer Assertion and HoK Assertions and to show where they are actually different.
DONE. See:
http://lists.oasis-open.org/archives/ws-sx/200604/msg00025.html
Prateek provided an overview of his additional scenarios. In summary his additional scenarios test for using:
1) SAML 1.1 Bearer case
2) SAML Asymmetric key case
3) SAML 2.0 Bearer case "on behalf of"
4) SAML 2.0 Asymmetric "on behalf of"
Note: Some people thought that we could collapse scenario 3) and 4) into a single "on behalf of"
5) SAML 2.0 delegation
b) SC/Trust Interop document
http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/17331/SX-Interop.doc
AI-2006-02-15-07 - TC members to come to the April F2F with data on when they would be ready to carry out SC/Trust interop.
Microsoft needs one week from when we have a stable spec document and interop document. They can do the 6 scenarios in the document edited by Marc.
IBM needs about two weeks from when we have a stable spec document and interop document. They might not do all scenarios right away. IBM would prefer to do a virtual interop. IBM might have more than one implementation.
BEA cannot yet commit to doing the interop.
HP needs about a month from now to be ready to interop. HP is especially interested in some of the additional scenarios offered by Prateek.
Oracle cannot yet commit to doing interop.
Nortel cannot yet commit to doing any interop.
Nokia cannot yet commit to doing any interop.
TIBCO cannot yet commit to doing any interop.
Some companies that are not present at this time include: BMC, Fujitsu, Sun, Layer7 and Verisign.
AI-2006-04-04-09 - Chairs to check with absent companies on their plans for SC/Trust interop.
Once we have the combined document the Chairs will ask:
a) when the interop participants can start
b) how long of virtual support they can support
c) the order of scenarios they plan to implement.
AI-2006-04-04-07 - Marc Goodner with help from Prateek Mishra to create a merged interop scenarios document.
AI-2006-03-29-04 - Marc Goodner to update interop doc with resolution of issue 47 before F2F.
Pending.
b) SC/Trust message examples
http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/17535/C2STS-msg-examples-ed-01.zip
Note: Partially complete. These flows "may" be
AI-2006-04-04-08 - Marc Goodner with help from Prateek Mishra to document interop message flows based on a future revised version of SC/Trust.
6. Discuss next steps
Kelvin enumerated some of the items to be discussed:
a) schedule for going to CD
b) possible future F2F.
CD discussion
Kelvin suggested the current plan should be to select Working Drafts for SC/Trust for interop, do the interop, fix the specifications and then create a CD output from that process.
Paul suggested the first question is to determine when we can get Working Drafts covering the results of this meeting. The meeting agreed to have revised SC/Trust documents by April 16 so that the May 3 SX meeting can evaluate the then Review issues. The interop documents would be made ready for the May 3 SX meeting. Permitting at least 8 weeks for interop preparation leads to a virtual interop event of July 10-21.
Possible future F2F
Heather suggested we schedule a F2F since it is so hard to get common time on everyone's calendars.
Chris initially suggested having a F2F immediately after the interop but Kelvin suggested that would not be good since we might want to cancel it at the last minute if there was no work to be done. Paul suggested having a meeting Sept. Abbie suggested that he might be able to host a meeting in Ottawa in Sept.
AI-2006-04-05-04 Chairs to do further work on a F2F meeting time and location.
7. Adjournment
The meeting adjourned at 3:00pm EST.
/paulc
Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (613) 225-5445 Fax: (425) 936-7329
mailto:Paul.Cotton@microsoft.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]