[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [VER 1] WS-SX TC F2F Minutes, Austin, TX, Apr 4-5 2006
WS-SX TC F2F Minutes, Austin, TX, Apr 4-5 2006
NOTE: THIS VERSION COVERS RESULTS FROM TUE APR 4. ITEMS TO BE PROCESSED ARE MARKED AS "OPEN".
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 revised wording for Rule 5 re use of multiple signatures for Issue 52.
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.
1. Call to order/roll call
Present:
<to be supplied>
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 revised wording for Rule 5 re use of multiple signatures for Issue 52.
OPEN awaiting above action item.
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. Marc will send an initiating email for this issue.
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
OPEN.
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
OPEN.
i028 Werner Dittmann Multiple supporting tokens of the same type?
See: http://lists.oasis-open.org/archives/ws-sx/200603/msg00079.html
OPEN.
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).
OPEN.
i031 Clarification for UsernameToken assertion
Pending on Issue 30.
OPEN.
i033 Identify security header components that are encrypted
No discussion by email has occurred since last week's meeting. OPEN.
AI-2006-03-29-01 Gudge owes Prateek a response (to message 82) for issue 33.
Unlikely to be done before F2F.
OPEN.
i048 Binding Assertions should support Operation subjects
AI-2006-03-29-02 Tony Gullota to provide further examples illustrating issue 48 in time for the F2F.
http://lists.oasis-open.org/archives/ws-sx/200603/msg00085.html
Tony Gullota's proposal:
http://lists.oasis-open.org/archives/ws-sx/200603/msg00065.html
OPEN.
i053 Message parts to be protected using BootstrapPolicy
http://lists.oasis-open.org/archives/ws-sx/200603/msg00119.html
OPEN.
i054 Clarification on Signature Protection property and various SupportingTokens
http://lists.oasis-open.org/archives/ws-sx/200603/msg00120.html
OPEN.
i055 Clarification on RequireDerivedKeys and X509Token under
AsymmetricBinding
http://lists.oasis-open.org/archives/ws-sx/200603/msg00121.html
OPEN.
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. AOB
OPEN.
7. Adjournment
OPEN.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]