http://docs.oasis-open.org/ws-sx/issues/ Date: 2006/07/25 Revision: 38 spec schema soap wsdl policy all interop New Active Pending Review Deferred Closed Dropped The specification is not clear in the difference between revocation and canceling a security token. Assume the following scenario: A WS consumer requests a token from a STS and includes the token in a SOAP message sent to the WS provider. Now the WS consumer may cancel the token at any point of time. The specification does not state the consequences of canceling a token. During our discussion, we came to following clarification: The cancel operation is a purely local operation on the STS. After canceling a token, a STS MUST not validate or renew the token. A STS MAY initiate the revocation of a token, however, revocation is out of scope of this specification and a client MUST not rely on it. ws-trust ws-trust spec editorial Martijn DeBoer Editors I'd suggest the following wording for clarification for "chapter 8: Cancel Binding": Cancel - When a previously issued token is no longer needed, the Cancel binding can be used to cancel the token. After canceling a token at the issuer, a STS MUST not validate or renew the token. A STS MAY initiate the revocation of a token, however, revocation is out of scope of this specification and a client MUST NOT rely on it. If a client needs to ensure the validity of a token, it must validate the token at the issuer. Proposal 1 accepted on Jan 11 TC call Moved to review at Jan 18th TC call based on changes in ws-trust ed-01-r3 Moved to closed at Jan 25th TC call. Section 5.1 Not clear with signed parts when you sign the body you can't sign the pieces No way to sign a child element of body, need to use signed elements for that ws-sp spec editorial First F2F Closed as duplicate of i011 on Jan 11 TC call i011 Evaluate the use of the term binding in the specs. ws-sc ws-sp ws-trust spec editorial First F2F Prateek Mishra Line 228 - Add "Note that services might accept messages containing more tokens than those specified in policy" as a second sentence. Line 229 - Change to read "Any necessary key transport mechanisms" Line 230 - Change to read "Any required message elements (e.g. timestamps) in the wsse:Security header." Line 233 - Remove this bullet. Add a new bullet ( after line 232 ) that reads; "Various parameters, including those describing the algorithms to be used for canonicalization, signing and encryption." Proposal 1 accepted on Feb 22nd TC call. Revision 5 of SP contains resolution for review. Moved to Closed at April 4th F2F. Transitive closure spec dependencies ws-sc ws-sp ws-trust spec editorial First F2F Editors Editors to produce OASIS template formatted version and provide docs before Jan. 11th meeting. ws-sc ws-sp ws-trust spec editorial First F2F Tony Nadalin Editors completed and status changed to review per Jan 11 TC call Moved to closed at Jan 25th TC call. Editors to incorporate errata of WS-SP included in the contribution into initial draft before Jan. 11th meeting. ws-sp spec editorial First F2F Tony Nadalin Editors completed and status changed to review per Jan 11 TC call Moved to closed at Jan 25th TC call. i005 Editors to put schema and wsdl in well identified place. ws-sc ws-sp ws-trust schema wsdl editorial First F2F Tony Nadalin Editors completed and status changed to review per Jan 11 TC call Moved to closed at Jan 25th TC call. i005 OASIS requirement Need to pull out all examples as separate files ws-sc ws-sp ws-trust spec editorial First F2F Editors Support for different key pairs for sign and encrypt in SP should be allowed in asymmetric binding. See discussion thread. ws-sp spec design First F2F Hal Lockhart This proposal is intended to allow the Asymmetric Binding to permit the use of distinct key pairs for encryption and signing. Replace the text at the beginning of WS-SP section 8.5: The AsymmetricBinding assertion is used in scenarios in which message protection is provided by means defined in WSS: SOAP Message Security. This binding has two binding specific token properties; [Initiator Token] and [Recipient Token]. If the message pattern requires multiple messages, this binding defines that the [Initiator Token] is used for the message signature from initiator to the recipient, and for encryption from recipient to initiator. The [Recipient Token] is used for encryption from initiator to recipient, and for the message signature from recipient to initiator. With: The AsymmetricBinding assertion is used in scenarios in which message protection is provided by means defined in WSS: SOAP Message Security using asymmetric key (Public Key) technology. Commonly used asymmetric algorithms, such as RSA, allow the same key pair to be used for both encryption and signature. However it is also common practice to use distinct keys for encryption and signature, because of their different lifecycles. This binding enables either of these practices by means of four binding specific token properties: [Initiator Token], [Recipient Token], [Initiator Signature Token], [Initiator Encryption Token], [Recipient Signature Token] and [Recipient Encryption Token]. If the same key pair is used for signature and encryption, the [Initiator Token] and [Recipient Token] properties are used. If the message pattern requires multiple messages, this binding defines that the [Initiator Token] is used for the message signature from initiator to the recipient, and for encryption from recipient to initiator. The [Recipient Token] is used for encryption from initiator to recipient, and for the message signature from recipient to initiator. If distinct key pairs are used for signature and encryption, the [Initiator Signature Token], [Initiator Encryption Token], [Recipient Signature Token] and [Recipient Encryption Token] properties are used. If the message pattern requires multiple messages, the [Initiator Signature Token] is used for the message signature from initiator to the recipient. The [Initiator Encryption Token is used for the response message encryption from recipient to the initiator. The [Recipient Signature Token] is used for the response message signature from recipient to the initiator. The [Recipient Encryption Token is used for the message encryption from initiator to the recipient. Note that in each case, the token is associated with the party (initiator or recipient) who knows the secret. Immediately below the text: /sp:AsymmetricBinding/wsp:Policy/sp:RecipientToken/wsp:Policy The policy contained here MUST identify one or more token assertions. Insert: /sp:AsymmetricBinding/wsp:Policy/sp:InitiatorSignatureToken This assertion indicates a requirement for an Initiator Signature Token. The specified token populates the [Initiator Signature Token] property and is used for the message signature from initiator to recipient. /sp:AsymmetricBinding/wsp:Policy/sp:InitiatorSignatureToken/wsp:Policy The policy contained here MUST identify one or more token assertions. /sp:AsymmetricBinding/wsp:Policy/sp:InitiatorEncryptionToken This assertion indicates a requirement for an Initiator Encryption Token. The specified token populates the [Initiator Encryption Token] property and is used for the message encryption from recipient to initiator. /sp:AsymmetricBinding/wsp:Policy/sp:InitiatorEncryptionToken/wsp:Policy The policy contained here MUST identify one or more token assertions. /sp:AsymmetricBinding/wsp:Policy/sp:RecipientSignatureToken This assertion indicates a requirement for a Recipient Signature Token. The specified token populates the [Recipient Signature Token] property and is used for the message signature from recipient to initiator. /sp:AsymmetricBinding/wsp:Policy/sp:RecipientSignatureToken/wsp:Policy The policy contained here MUST identify one or more token assertions. /sp:AsymmetricBinding/wsp:Policy/sp:RecipientEncryptionToken This assertion indicates a requirement for a Recipient Encryption Token. The specified token populates the [Recipient Encryption Token] property and is used for encryption from initiator to recipient. /sp:AsymmetricBinding/wsp:Policy/sp:RecipientEncryptionToken/wsp:Policy The policy contained here MUST identify one or more token assertions. Replace the text at the beginning of WS-SP section 8.5: The AsymmetricBinding assertion is used in scenarios in which message protection is provided by means defined in WSS: SOAP Message Security. This binding has two binding specific token properties; [Initiator Token] and [Recipient Token]. If the message pattern requires multiple messages, this binding defines that the [Initiator Token] is used for the message signature from initiator to the recipient, and for encryption from recipient to initiator. The [Recipient Token] is used for encryption from initiator to recipient, and for the message signature from recipient to initiator. With: The AsymmetricBinding assertion is used in scenarios in which message protection is provided by means defined in WSS: SOAP Message Security using asymmetric key (Public Key) technology. Commonly used asymmetric algorithms, such as RSA, allow the same key pair to be used for both encryption and signature. However it is also common practice to use distinct keys for encryption and signature, because of their different lifecycles. This binding enables either of these practices by means of four binding specific token properties: [Initiator Signature Token], [Initiator Encryption Token], [Recipient Signature Token] and [Recipient Encryption Token]. If the same key pair is used for signature and encryption, then [Initiator Signature Token] and [Initiator Encryption Token] will both refer to the same token. Likewise [Recipient Signature Token] and [Recipient Encryption Token] will both refer to the same token. If distinct key pairs are used for signature and encryption, then [Initiator Signature Token] and [Initiator Encryption Token] will refer to different tokens. Likewise [Recipient Signature Token] and [Recipient Encryption Token] will refer to different tokens. If the message pattern requires multiple messages, the [Initiator Signature Token] is used for the message signature from initiator to the recipient. The [Initiator Encryption Token] is used for the response message encryption from recipient to the initiator. The [Recipient Signature Token] is used for the response message signature from recipient to the initiator. The [Recipient Encryption Token] is used for the message encryption from initiator to the recipient. Note that in each case, the token is associated with the party (initiator or recipient) who knows the secret. Replace the text; /sp:AsymmetricBinding/wsp:Policy/sp:InitiatorToken This assertion indicates a requirement for an Initiator Token. The specified token populates the [Initiator Token] property and is used for the message signature from initiator to recipient, and encryption from recipient to initiator. With: /sp:AsymmetricBinding/wsp:Policy/sp:InitiatorToken This assertion indicates a requirement for an Initiator Token. The specified token populates the [Initiator Signature Token] and [Initiator Encryption Token] properties and is used for the message signature from initiator to recipient, and encryption from recipient to initiator. Replace the text: /sp:AsymmetricBinding/wsp:Policy/sp:RecipientToken This assertion indicates a requirement for a Recipient Token. The specified token populates the [Recipient Token] property and is used for encryption from initiator to recipient, and for the message signature from recipient to initiator. With: /sp:AsymmetricBinding/wsp:Policy/sp:RecipientToken This assertion indicates a requirement for a Recipient Token. The specified token populates the [Recipient Signature Token] and [Recipient Encryption Token] properties and is used for encryption from initiator to recipient, and for the message signature from recipient to initiator. Immediately below the text: /sp:AsymmetricBinding/wsp:Policy/sp:RecipientToken/wsp:Policy The policy contained here MUST identify one or more token assertions. Insert: /sp:AsymmetricBinding/wsp:Policy/sp:InitiatorSignatureToken This assertion indicates a requirement for an Initiator Signature Token. The specified token populates the [Initiator Signature Token] property and is used for the message signature from initiator to recipient. /sp:AsymmetricBinding/wsp:Policy/sp:InitiatorSignatureToken/wsp:Policy The policy contained here MUST identify one or more token assertions. /sp:AsymmetricBinding/wsp:Policy/sp:InitiatorEncryptionToken This assertion indicates a requirement for an Initiator Encryption Token. The specified token populates the [Initiator Encryption Token] property and is used for the message encryption from recipient to initiator. /sp:AsymmetricBinding/wsp:Policy/sp:InitiatorEncryptionToken/wsp:Policy The policy contained here MUST identify one or more token assertions. /sp:AsymmetricBinding/wsp:Policy/sp:RecipientSignatureToken This assertion indicates a requirement for a Recipient Signature Token. The specified token populates the [Recipient Signature Token] property and is used for the message signature from recipient to initiator. /sp:AsymmetricBinding/wsp:Policy/sp:RecipientSignatureToken/wsp:Policy The policy contained here MUST identify one or more token assertions. /sp:AsymmetricBinding/wsp:Policy/sp:RecipientEncryptionToken This assertion indicates a requirement for a Recipient Encryption Token. The specified token populates the [Recipient Encryption Token] property and is used for encryption from initiator to recipient. /sp:AsymmetricBinding/wsp:Policy/sp:RecipientEncryptionToken/wsp:Policy The policy contained here MUST identify one or more token assertions. Proposal 2 accepetd on March 1st TC call. Revision 5 of SP contains resolution for review. Moved to Closed at April 4th F2F. How does a security intermediary presents a sec token? How does it provide proof of possession of that token in the current message structure? See security agent use cases (.doc link). Continuing discussion: msg00016 msg00044 msg00050 ws-trust spec design Prateek Mishra Prateek Mishra Proposal 1 accepted on March 15th TC call. Revision 4 of Trust contains resolution for review. Moved to Closed at April 4th F2F. The WS-SX Charter states on lines 212-222 (red-lined version from WS-SX F2F): "This work will specifically define the following: 1. Mechanism for specifying what parts of the message must be secured, called protection assertions a. Such protection assertions must be able to specify integrity requirements at both the element and header/body level in a security policy binding (defined below) neutral manner. b. Such protection assertions must be able to specify confidentiality requirements at both the element and header/body level in a security policy binding (defined below) neutral manner. c. Such mechanisms must not require the use of XPath [21] but may provide it as an option." I think this clearly states that a mechanism will be defined that is able to specify integrity and confidentiality requirements at an element level without using XPath. However, section 5.1 of WS-SecurityPolicy states: "5.1 Integrity Assertions Two mechanisms are defined for specifying the set of message parts to integrity protect. One uses QNames to specify either message headers or the message body while the other uses XPath expressions to identify any part of the message." A similar introduction exists in section 5.2 and in both sections the followup text elaborates consistent with introductions. My interpretation is that this is inconsistent with part c of the quoted text from the charter above, because neither mechanism allows the the addressing at the element level without XPath (the first does not allow element addressing at all, the second uses XPath). Finally, what raised my concern in the first place was that I was looking for an element-specific non-XPath mechanism, which I thought would be described in section 5.1.1. I read the text several times, but only at the meeting when it was stated that SignedParts only applied to the Body as a whole did I realize that the text then was consistent. However, if only the Body can be addressed this does not meet the requirement of part a. in the quote from the charter above. Assuming my interpretation is correct, my suggestion is to either: 1. loosen the restriction in part c to say a mechanism such as XPath may be required or 2. add a 3rd mechanism to sections 5.1, 5.2 My concern also is that I am not aware of any 3rd mechanism. Possibly wsu:Id or xml:id could be inserted to a target element, but that might cause xml validation issues. ws-sp spec editorial Richard Levinson Frederick Hirsch Initial mail from Frederick, prepared as charter clarification during Jan 18th TC call. Closed with new ballot for charter clarification drafted per proposal 1 with typo corrections during Jan 18th TC call. Chairs have action (ai-08) to start a new ballot. While going over some details I noticed that it appears that each <ds:Signature> in the examples contains <ds:Signature>...</ds:Signature>. This should probably be <ds:SignatureValue>...<ds:SignatureValue>. See lines: 2376, 2604, 2626, 2751, 2973, 2990, 3124 ws-sp ws-sp spec editorial Richard Levinson Editors Assuming the issue is correct change the tag names to ds:SignatureValue Assigned to editors to make proposed change on Jan 11 TC call Moved to review based at Jan 18th TC call on changes in ws-sp ed-01-r3 Moved to closed at Jan 25th TC call. OASIS boilerplate (license, etc.) needs to be added to the XSD and WSDL files ws-sc ws-sp ws-trust schema wsdl editorial Jan 11 TC call Editors Editors prepared new drafts as oasis-wssx-ws-trust-1.0.xsd, oasis-wssx-ws-trust-1.0.wsdl oasis-wssx-ws-secureconversation.xsd Proposal 1 accepted at Jan 18th TC call, status changed to review. Moved to closed at Jan 25th TC call. Section 6.2.4 proposes the use of P_SHA-1 algorithm taken from rfc 2246 (TLS 1.0) for implementing a key agreement protocol. However, key agreement in rfc 2246 involves a somewhat different construction which uses P_SHA-1 only as a sub-component. (1) Is there an analysis or other material available to support the use of P_SHA-1 as proposed in WS-Trust? (2) P_SHA-1 is an iterative method that could theoretically generate keying material of unbounded size. It would seem that there would need to be some constraints on the sizes of Ent(req), Ent(resp) and the computed key. For example, would Ent(req) and Ent(resp) be required to be at least 160 bits? And, if so, what then would be the recommended size of the computed key? ws-trust spec design Prateek Mishra Prateek Mishra Close with no action. "Chris suggested the only change would be to add a new derived key algorithm based on P-SHA256. Prateek agreed this was orthogonal." Proposal 1 made and accepted on Feb. 8 TC call. The extension mechanism in the RequestSecurityToken and the RequestSecurityTokenResponse require the recipient fault if an attribute or an element is found that is not understood. The recipient can be required to return the attribute(s) or element(s) that it doesn't understand in defined format in the fault message. The error information can help cross vendor interoperability and even among different versions of the same vendor implementation. An implementation potentially can fall back to a mode of operation that does not use new extensions. Draft proposal: The recipient returns attribute name(s) and element name(s) that it doesn't understand in the fault message. ws-trust spec design C.Y. Chao C.Y. Chao From C.Y. Chao: WS-Trust line 367-368 (also 369-371, 430-432, and 433-435) Like ". . . If an element is found that is not understood, the recipient should fault. The recipient should list unrecognized elements and attributes in the detail element." Line 2058-2067 Error Handling section, add Error that occurred (faultstring) Unrecognized extensions found Fault code (faultcode) wst:UnknownExtension Fault detail (detail) . . . <UnknownElement>element name</UnknownElement> <UnknownAttribute>attribute name</UnknownAttribute> Close with no action. Agreed to proposal 2, close with no action, on feb 22nd Tc call. Should the sp:SignedParts mechanism (lines 592-605) allow specification of header elements targeted to a specific s11:actor or s12:role? ws-sp spec design Michael McIntosh Michael McIntosh Section 4.1.1 SignedParts provides a mechanism to specify which "parts" of a message are required to be integrity protected. The current text indicates that, for the sp:SignedParts element, "If no child elements are specified, all message headers targeted at the UltimateReceiver role [SOAP12] or actor [SOAP11] and the body of the message MUST be integrity protected." However, it isn't clear whether sp:Header elements, when specified, impact all matching header elements or only those targeted at the UltimateReceiver. Also, there is currently no way to specify that a header not targeted to UltimateReceiver must be signed. Proposal: @ Line 575 Syntax <sp:SignedParts ...="" > <sp:Body />? <sp:Header Name="xs:NCName"? Namespace="xs:anyURI" Target="xs:anyURI" ...="" />* ... </sp:SignedParts> @ Line 599 /sp:SignedParts/sp:Header/@Name This optional attribute indicates the local name of the SOAP header to be integrity protected. If this attribute is not specified, all SOAP headers whose namespace and target match the Namespace and Target attributes are to be protected. /sp:SignedParts/sp:Header/@Namespace This required attribute indicates the namespace of the SOAP header(s) to be integrity protected. /sp:SignedParts/sp:Header/@Target This optional attribute indicates the role [SOAP12] or actor [SOAP11] of the SOAP header(s) to be integrity protected. If this attribute is not specified, all SOAP headers targeted at the UltimateReceiver role [SOAP12] or actor [SOAP11] whose namespace matches the Namespace attribute are to be protected. Proposal 2 accepted at April 5th F2F. Editor version with resolution applied available for review. Moved to Closed at May 3rd TC call. Should the sp:RequiredElements mechanism (lines 735-740) allow specification of otherwise optional elements that are not children of soap:Header? ws-sp spec design Michael McIntosh Michael McIntosh Drop the issue. Close with no action Agreed to proposal 2, close with no action, on feb 22nd Tc call. Should there a be way to specify that a signature reference for a given SignedPart or SignedElement must use an absolute XPath expression? ws-sp spec design Michael McIntosh Michael McIntosh Rationale for proposal Before Line 606 Add: /sp:SignedParts/sp:Header/@UsePositionalReference This optional attribute indicates that the specified SOAP header element must be integrity protected in a way that prevents repositioning the element in the message. If this attribute is "1" (true) and XML Signature is used to protect the integrity of the element, the reference must use an absolute path XPath expression. If this attribute is not specified the default is "0" (false). Before Line 626 Add: /sp:SignedElements/@UsePositionalReference This optional attribute indicates that the specified element(s) must be integrity protected in a way that prevents repositioning the element(s) in the message. If this attribute is "1" (true) and XML Signature is used to protect the integrity of the element(s), the reference(s) must use an absolute path XPath expression. If this attribute is not specified the default is "0" (false). Proposal 2 ammended during April 5th F2F discussion. Proposal 3 accepted at April 5th F2F. Editor version with resolution applied available for review. Moved to Closed at May 3rd TC call. define a limited set of XPath expressions that MUST be supported by an implementation (and list explicitly ) ws-sp spec design Frederick Hirsch Frederick Hirsch At Feb. 8 TC call Frederick reported that he was not able to get any concrete examples. His developers did agree that doing less is always better. Since there are no concrete examples the TC agreed to close this issue with no action. Section 6.2.4 of WS-Trust describes the use of the P_SHA1 function to generate computed keys. It does not provide guidance on minimum size of entropy required for this function. My crypto 101 guess is that a minimum of 20 bytes is required for each parameter but I would like more informed guidance and have it included in the table. Is there any advantage to choosing longer strings for Ent(req) or Ent(res)? ws-sc ws-trust spec design Prateek Mishra Prateek Mishra Proposal 1 accepted on April 19th TC Call. Editor version with resolution applied available for review. Accepted edits as applied. AI-2006-05-03-04 OASIS template invalidated section numbers used to cross reference throughout SP. This needs to be corrected. ws-sp spec editorial Feb 8th TC call Editors See this message for detailed line number changes. Proposal 1 accepted on March 1st TC call. Editor version with resolution applied available for review. Accepted edits as applied. In chapter 6 the spec introduces several properties to control some behaviour. The actual XML tags to set the properties is given in chapter 7. It is somehow difficult to link the properties defined in chapter 6 to the actual XML tags defined in chapter 7. For example: the [Protection Order] property can have several values. Chapter 7 then defines the real XML tags as e.g. <sp:EncryptBeforeSigning /> to set this property. Because this property can have several values there are several such XML tags to set this property. However, these XML names bear no direct link to the property. ws-sp spec design Werner Dittmann Use the following notation to set a multi value property: <sp:ProtectionOrder value="EncryptBeforeSigning" /> Such a notation would also simplify parsing because a parser has to look for one tag name only and can use the attribute to set the property's value. Other properties are defined as boolean (true/false) properties. However, the actual XML tag names to set the property differ from the specified property name - this is somehow confusing. Take the Signature Protection property as an example: to set it you have to use the XML tag <sp:EncryptSignature />. Why no use something like: <sp:SignatureProtection value="on" /> or <sp:SignatureProtection value="Encrypt" /> or just <sp:SignatureProtection /> or something similar to make clear which property is set or defined. Close with no action. Proposal 2 accepted, to close with no action, at Feb 22nd TC call. The table at line 1280ff defines two properties [Sym KS] and [Asym KS]. Both propteries were not shown in the bullet list starting at line 1263. Should these two properties read [Sym Sig] and [Asym Sig]? The table starting at line 1282 defines a property [C14n]. This property name is the same as the abbreviation for C14n in table starting at line 1277. This is not wrong, but choosing different names would make it more clear. ws-sp spec editorial Werner Dittmann The table at line 1280ff defines two properties [Sym KS] and [Asym KS], these should read [Sym Sig] and [Asym Sig] which would match bullett list at line 1263. The table starting at line 1282 defines a property [C14n], this should be spelled out as a property name such as; [Canonicalization], [C14N algorithm] or [C14N Alg] or some such. Editors to implement proposed changes (extracted and recorded in proposal 1), agreed on Feb 22nd TC call. Revision 5 of SP contains resolution for review. Moved to Closed at April 4th F2F. In "EncryptBeforeSigning" the spec states that both keys MUST derived from the same source. What does this mean? Use the same certificate for both actions (for example if a X509 cert is used). In that case this seems an unnecessary restriction. At least WS Security does not mandate this. Also using the same cert to encrypt and sign is not a good security practice. Proposed direction: Extend the ws-sp spec to support different key sources. ws-sp spec editorial Werner Dittmann Determined duplicate of issue 9 on on March 1st TC call, closed with no action. i009 If the policy uses EndorsingSupportingTokens _and_ sets [Token Protection] then I have the same behaviour as defined for SignedEndorsingSupportingTokens. Is that true? On the other hand if I use SignedEndorsingSupportingTokens and do _not_ set [Token Protection] - what should be the result in that case? Proposed direction: Clarify behaviour of these interdependencies. ws-sp spec design Werner Dittmann At the beginning of chap 8 add something like: How [Token Protection] interacts with supporting tokens If [Token Protection] is true, then each signature covers the token that generated it. So the main signature ( the one over the message headers and body ) covers the main token (e.g. [Protection Token] in a symmetric binding). Endorsing signatures cover the endorsing token. For a signed SupportingToken the supporting token is covered by the main message signature. If you have a SignedEndorsingSupportingToken and [Token Protection] is set to 'true' then the supporting token is signed twice, once by the main signature and once by the endorsing signature. Editors to implement proposed changes (extracted and recorded in proposal 1) in section 8, agreed on Feb 22nd TC call. Revision 5 of SP contains resolution for review. Moved to Closed at April 4th F2F. Here the spec defines "LaxTimestampFirst" and "LaxTimestampLast", both define that a Timestamp MUST be included. On the other hand in chapter 6.2 [Timestamp] the spec defines another way to switch Timestamps on/off. Which one rules? Proposed direction: Clarify behaviour of these interdependencies. ws-sp spec design Werner Dittmann In order for [Security Header Layout] property values of LaxTimeStampFirst or LaxTimeStampLast to be valid [Timestamp] MUST be set to true. This is called out in the assertions description in section 7.2 but should be called out in section 6 as well. Editors to implement proposed changes (extracted and recorded in proposal 1) to add Section from 7.2 to section 6. Agreed on Feb 22nd TC call. Revision 5 of SP contains resolution for review. Moved to Closed at April 4th F2F. Using token inclusion values (chap 5.1.1) one can specify when to include a token. On the other hand in chap 5.3.3 X509Token Assertion there are ways defined how to reference a X509 token. For example if "RequireIssuerSerialReference" is set and the inclusion value is "always": shall the token be included in the message? Which token shall the receipient take - the included one or the referenced? With respect to the WS Security specification I interpret the inclusion value "always*" or "once" without any additional "Require*" assertion as "include the token as a BinarySecurityToken and reference it using a Reference in the SecruityTokenReference". Is this a correct interpretation? Also, with respect to WSS how to interpret or act on the RequireEmbeddedRefernce assertion? WSS does not specify an "embedded" mechanism for X509 certificates. Proposed direction: Clarify behaviour of the "token inclusion" and "token reference" interworking to avoid misinterpretations and probable interop problems. ws-sp spec design Werner Dittmann Werner Dittmann See discussion of this proposal in March 8 TC call minutes Proposal 2 accepted on March 15th TC call. Revision 5 of SP contains resolution for review. Moved to Closed at April 4th F2F. Can a Policy have more than one supporting token (of the same type), e.g. multiple SupportingTokens or multiple EndorsingSupportingTokens? Proposed direction: IMHO we need an "overall" ws-sp outline to define which assertions are allowed at a specific level, for example similar to (a)symmetric binding outline but for to top level policy file. See continuing discussion: msg00079 ws-sp spec design Werner Dittmann Werner Dittmann Closed with no action at April 5th F2F as the TC agreed that the answer to this question is yes.. i062 Every supporting token can have more than one token assertion, e.g. X509 token assertions. If there are more than one such token assertion which on shall be used to sign/encrypt additional SignedParts or EncryptedParts if some are definied? Proposed direction: Define and insert some clarification. ws-sp spec design Werner Dittmann Add the following to section 8, supporting tokens: All of them (sic "tokens included in the supporting tokens") should sign and encrypt the various message parts. Ordering of elements (tokens, referencelists etc.) in the security header would have to be used to determine which order encryptions occurred in. Proposal 1 accepted on March 1st TC call. Revision 5 of SP contains resolution for review. Moved to Closed at April 4th F2F. An implementation that uses Security Policy Language has to know how to populate the required tokens, e.g. UsernameToken or X509 tokens. Because a policy file usually contains several token assertions there should be a mechanism avaliable to identify a token assertion. For example if a policy requires two UsernameToken in a supporting token the application that creates the message needs a way to link the different UsernameToken assertions to the user data records that contains username, password, etc. To do so the application shall be able to identify the UsernameToken and use this identifier as a link to the user data record. Simliar mechanisms are required to locate the correct X509 certificate in a keystore, for example. Proposed direction: Add an Id or name attribute or to token assertions. Any other ideas how to identify token in a Poliy file and associated them with real user/alias data? See AI-2006-03-15-01 ws-sp spec design Werner Dittmann Werner Dittmann Proposal 2 accepted at April 5th F2F. Editor version with resolution applied available for review. Moved to Closed at May 3rd TC call. The UsernameToken defines additonal (optional) assertions that specify the WSS spec version. IMHO this is not enough to fully specify a UsernameToken. For example a UsernameToken may have a additonal elements such as a creation time. The WSS specs do not define in any way if such elements shall be included or not (some are recommended but no mandated). Proposed direction: The UsernameToken assertion should be extended to better reflect the WSS username token elements and attributes. *Note* depends on resolution to issue 30 See continuing discussion msg00081 msg00083 ws-sp spec design Werner Dittmann Werner Dittmann Revised from original. Proposal 1 accepted with ammendmets on June 7th TC call. Revision 7 of SP contains resolution for review. Accepted edits as applied. AI-2006-04-12-01 AI-2006-04-12-02 At the end of section 5.3.1 it says: Note: While Username tokens could be used cryptographically, such usage is discouraged in general because of the relatively low entropy typically associated with passwords. This specification does not define a cryptographic binding for the Username token. A new token assertion could be defined to allow for cryptographic binding. I believe that WS-SP should enable all the functionality defined in the referenced specs. Specifically, WSS 1.1 defines an algorithm for deriving keys from passwords. I think WS-SP should support this and allow organizations decide for themselves if they wish to use them or not. There are already warnings about the issues in the security considerations section of the WSS 1.1 Username Token Profile Security Considerations section. ws-sp spec editorial Hal Lockhart Hal Lockhart Proposal 1 accepted on March 15th TC call. Revision 5 of SP contains resolution for review. Moved to Closed at April 4th F2F. It appears that use of the SymmetricBinding and Asymmetric binding assertion implies encryption over several components of the security header, including the timestamp, Supporting tokens and SignedSupporting tokens. This is not stated in the specification but can be gleaned from the construction given in Appendix C. It would be helpful to implementors if this was made explicit in Sections 7.3 and 7.4 Continuing discussion msg00071 msg00082 ws-sp spec editorial Prateek Mishra Prateek Mishra Add the following sentence to Sections 7.4 (at end of first paragraph) and 7.5 (at end of first paragraph): Use of this binding assertion implies that the following tokens, if present in the security header of the request or response message, MUST be encrypted: timestamp, Supporting tokens and SignedSupporting tokens. Proposal 2 accepted on May 31st TC call. Revision 7 of SP contains resolution for review. Accepted edits as applied. AI-2006-03-29-01 AI-2006-05-10-01 See proposal for details ws-trust spec editorial Frederick Hirsch Frederick Hirsch 1) Section 1.2, Remove line 54, modify line 55 to be "Establishing, managing and assessing trust relationships." ("Managing trusts" is unclear). 2) Section 1.4 Neither schema (line 62) or wsdl (line 65) are located in the oasis docs directory. Should a draft be placed there? 3) Remove material in 1.5 from lines 109-115 Replicated in next section where it belongs. 4) Line 139 add [ for WS-PolicyAttachment 5) line 261 s/. As well,/ or/ 6) Line 457, s/As well, /Additional 7) move lines 478-480 to 472, replace "As well, it is" with "It is also" The mechanisms defined in this specification apply to both symmetric and asymmetric keys. As an example, a Kerberos KDC could provide the services defined in this specification to make tokens available; similarly, so can a public key infrastructure. In such cases, the issuing authority is the security token service. It should be noted that in practice, asymmetric key usage often differs as it is common to reuse existing asymmetric keys rather than regenerate due to the time cost and desire to map to a common public key. In such cases a request might be made for an asymmetric token providing the public key and proving ownership of the private key. The public key is then used in the issued token. A public key directory is not really a security token service per se; however, such a service MAY implement token retrieval as a form of issuance. It is also possible to bridge environments (security technologies) using PKI for authentication or bootstrapping to a symmetric key. 8) Line 490, replace "Subsequent" with "Additional". Line 492, remove " (e.g. multiple simultaneous exchanges) " 9) Line 560 s/post-dated/postdated/ 10) Line 694, change last OK in table to "Issuer scope". 11) Line 743, s/and are/that is 12) Line 762, Is link really to Section 6.1 or to 4.1? 13) Line 878, Replace "Two or more RSTR elements are returned in the collection." with "Each RequestSecurityTokenResponse element is an individual RSTR." Add text "Two or more RSTR elements are returned in the collection." to end of line 876, for description of collection. 14) Line 927 add "This element schema is defined using the RequestSecurityTokenResponse schema type." (this merely reiterates line 916 in the text describing the element). 15) Line 1128 indicate request and response separately. 16) Table entries at 1219 s/request/Trust service 17) Table 1225, is example missing token to be validated? 18) Any additional requirements/description on validation of envelope needed in section 7? e.g. validate for specific role? 19) Is ws:LChallenge correct at line 1352? 20) Section 8.6, generally sign with private key associated with certificate, not certificate... (lines 1447, 1484) 21) 1699 s/binding/other bindings Proposal 1 accepted on March 3rd conference call. Revision 4 of Trust contains resolution for review. Moved to Closed at April 4th F2F. Text seems to imply requestor can fault upon receiving a response. See Line 386, also lines 432 and 435. It isn't clear how the receiver of a response (the requestor) can fault if the message exchange pattern is complete. ws-trust spec editorial Frederick Hirsch Proposal, remove lines 386-7. Likewise lines 432, 435. The TC discussed this issue and decided the document did not require any change. Closed with no action on Feb 22nd TC call. Is "pre-authentication" a well defined term? What does it mean to pre-authenticate using SSL/TLS? ws-trust spec editorial Frederick Hirsch Frederick Hirsch At Line 232, section 2. Add sentence "Authenticating the server at the transport layer can mitigate the risk of spoofed servers." Change the second sentence of the paragraph at lines 229-233 (second to last paragraph in section 2 introduction) to read as follows: "Network and transport protection mechanisms such as IPsec or TLS/SSL can be used in conjunction with this specification to support different security requirements and scenarios. If available, requestors should consider using a network or transport security mechanism to authenticate the service when requesting, validating, or renewing security tokens, as an added level of security." Detailed changes are s/perform pre-authentication of the recipient/authenticate the service/ s/tokens//tokens,/ Proposal 2 accepted on March 22nd TC call. Revision 4 of Trust contains resolution for review. Moved to Closed at April 4th F2F. Add element extensibility to RequestSecurityTokenResponseCollection schema. This would potentially allow bindings to define information associated with collection or to avoid repeating material in each SecurityTokenResponse, to give examples. Note that IssuedTokens shares the same schema as RequestSecurityTokenResponseCollection, so resolution applies to this element as well. ws-trust spec schema design Frederick Hirsch Frederick Hirsch 1) Insert before line 879: /wst:RequestSecurityTokenResponseCollection/{any} This is an extensibility mechanism to allow additional elements, based on schemas, to be added. 2) Insert before line 931 /wst:IssuedTokens/{any} This is an extensibility mechanism to allow additional elements, based on schemas, to be added. 3) Update schema accordingly. Proposal 1 accepted on March 3rd conference call. Revision 4 of Trust contains resolution for review. Moved to Closed at April 4th F2F. Can a computed key mechanism be implicit and not indicated with a ComputedKey element? (lines 744, 757) ws-trust spec design Frederick Hirsch Frederick Hirsch At Line 744 s/is/may be/ Add line to 757: "Use of the ComputedKey element is optional but SHOULD be used if a key needs to be computed." Proposal 2 accepted on March 22nd TC call. Revision 4 of Trust contains resolution for review. Moved to Closed at April 4th F2F. At Line 415, WS-Trust does not define a "anonymous" URI for the generic case of no correlation - but implies it is needed generically ws-trust spec editorial Frederick Hirsch Frederick Hirsch At Line 415, WS-Trust core define an "anonymous" URI for the generic case of no correlation - http://docs.oasis-open.org/ws-sx/ws-trust/200512/anonymous-context TC agreed to close with no action March 3rd conference call. lines 530-535 of ws-trust-1[1].3-spec-ed-01-r03-diff state: [quote] /wst:RequestSecurityToken/wst:Claims This optional element requests a specific set of claims. In most cases, this element contains claims identified as required in a service's policy. Refer to [WS-Policy] for examples of how a service uses policy to specify claim requirements. The @Dialect attribute specifies a URI to indicate the syntax of the claims. No URIs are predefined; refer to profiles and other specifications to define these URIs. [\quote] We are unable to follow what is meant here. What language is used to specify claims for different token types? There is a reference here to examples in WS-Policy (Sep 2004) but no other detail. WS-Policy (Sep 2004) does not specifically discuss this issue nor does it offer an example of a service using a policy to specify claim requirements. I am also not sure what the role of "profiles" and the @Dialect attribute is. Is this a reference to WSS 1.x profiles or to forthcoming profiles to developed as part of WS-SX? Is the intent here to allow policies from WS-SecurityPolicy to be expressed? ws-trust spec design Prateek Mishra Prateek Mishra *Note* from March 8th TC call "Prateek would like the "dialect" extensibility point to be described as just that. Note that the proposal in msg00117 (this one) is wrong." My guess is that this should reference is WS-SecurityPolicy with language like: [quote] This optional element requests a specific set of claims. In most cases, this element contains claims identified as required in a service's policy. Policy expressions taken from WS-SecurityPolicy may be used to describe the claims sought by the requestor. [\quote] But this still leaves open the role of @Dialect. So I need the questions given above to be answered first, before I can propose alternative text. Proposal 2 accepted on March 15th TC call. Revision 4 of Trust contains resolution for review. Moved to Closed at April 4th F2F. Clarification on token propagation of SCT required when STS has no prior knowledge of which parties the requester needs a token for. WS-SC defines SCT token propagation in order to distribute an SCT and its POP token to the requester (context initiator) and the other parties (endpoint for secured requests). Section 3 (lines 255 ff), Establishing Security Contexts, refers to the mechanisms in WS-Trust for token propagation. If the STS has no prior knowledge of which parties the requester needs a token for, WS-Trust provides two alternatives to define theses parties in the RST: wsp:AppliesTo in RST and RSTR, Section 4.2.1 (lines 677 ff): Both the requestor and the issuer can specify a scope for the issued token using the <wsp:AppliesTo> element. wsp:AppliesTo can be used to carry wsa:EndpointReference elements which contain endpoint URLs. Authorized Token Participants, Section 9.5 (lines 1969 ff): This parameter is typically used when there are additional parties using the token or if the requestor needs to clarify the actual parties involved (for some profile-specific reason). wst:ParticipantType can contain an arbitrary structure according to the ws-trust XSD. From the quotes above, my guess is that WS-SC should refer to the Authorized Token Participants extension element for the RST and should give an example or enhance the existing SCT Request Example (section 3.2, lines 323 ff) in section 3.3 of the WS-SC spec. ws-sc spec design Martin Raepple Martin Raepple - Sec. 3.3: Add a paragraph that explains how the requester uses wsp:AppliesTo for Token Propagation if the STS has no prior knowledge of which parties the requester needs a token for - Sec. 3.3: Add an SCT request example that uses wst:AppliesTo for this scenario Proposal 1 accepted on March 3rd conference call. Revision 5 of SC contains resolution for review. Moved to Closed at April 26th TC call. WS-SC introduces the Security Context (SCT) Token which contains a unique identifier for a shared security context among the context initiator (requester) and (1 to n) service endpoints. There are certainly cases where the service endpoint is actually not one system but a collection of systems (server farm) used for cluster computing. Server farms are typically co-located with a load balancer which enables communication between the different servers of the cluster and the users of the cluster and may perform some type of load balancing Based on the assumption that the servers in the cluster do not share a common address space or use any other means to synchronize stateful resources (such as the security context), the load balancer needs to send all subsequent requests for the same client to same server which has access to the previously created security context as part of the SCT establishment phase (see section 3.3). The load balancer could certainly look at the wsse:security/wsc:SecurityContextToken/wsc:Identifier element to determine the context identifier and route the request to the server according to same sort of mapping. But this could have an impact of the overall performance since the load balance has to look inside the content of the HTTP request and parse the content of the SOAP message. A much faster approach would be to carry the security context identifier in the HTTP header. Such an HTTP binding for WS-SC could specify the relationship between the WS-SC security context and the HTTP header and should define the name and semantics of new custom HTTP header(s). ws-sc spec design Martin Raepple Closed with no action as TC deemed out of scope on March 1st TC call. In the definition of RequestTypeEnum (line #80) we should have one more enumeration with the value "http://schemas.xmlsoap.org/ws/XXXX/XX/trust/Validate" ws-trust schema editorial Ruchith Fernando Editors Include the following in the RequestTypeEnum definition: <xs:enumeration value='http://schemas.xmlsoap.org/ws/XXXX/XX/trust/Validate' /> *Note* WS-Trust uses the missing URI: http://docs.oasis-open.org/ws-sx/ws-trust/200512/Validate Proposal 1 accepted on March 3rd conference call. Editor version of schema with resolution applied available for review. Accepted edits as applied. AI-2006-05-03-05 line 1185: ". In other cases an authorization token MAY be returned. " I dont know what an authorization token is; this should be clarified or this line removed. See discussion ws-trust spec editorial Prateek Mishra Tony Nadalin 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." Proposal 2 accepted at April 4th F2F. Revision 5 of Trust contains resolution for review. Moved to Closed at April 26th TC call. The two Signature elements in the Security Context example in section 8 have the same Id attribute values, "sig1" at lines 938 and 944. ws-sc spec editorial Frederick Hirsch Editors Remove Id attributes from the two Signature elements in the example at lines 938 and 944. Proposal 1 accepted on March 15th TC call. Revision 4 of SC contains resolution for review. Moved to Closed at April 4th F2F. The WSS 1.x specifications defines <wsse:BinarySecurityToken> as a container for carrying legacy or non-XML security tokens. WS-SP includes assertions for X.509 certificates and Keberberos tickets as specific instances of binary security tokens but does not include any way of referencing a generic binary security token of an arbitrary valuetype. The enterprise use-case of interest is a situation where a legacy requestor generates a SOAP message with a binary security token with value type set by prior agreement (e.g., LegacyFooToken). There is a corresponding use-case for a legacy responder, where the responder requires some form of pre-existing security token. In each case, it would aid interoperability if WS-SP supported expression of BinarySecurityToken with a certain value type. No other semantics would be associated with tokens conforming to this assertion. ws-sp spec schema design Prateek Mishra Include a new token type in Section 5.3 Section 5.3.11 This element represents a requirement to include an arbitrary binary security token in the security header. The assertion includes information about the URI that must be provided by the security token's ValueType attribute. /sp:BinarySecurityToken This identifies a Binary Security Token assertion /sp:BinarySecurityToken/ValueType This required element specifies the URI that must be provided by the corresponding security token's ValueType attribute. /sp:BinarySecurityToken/Policy This optional element specifies additional requirements for the use of the sp:BinarySecurityToken assertion Closed with no action on March 15th TC call (per proposal 2). Prateek will open a new issue if he thinks additional material should be added to the specification. See AI-2006-03-15-01. There some ambiguity in the discussion under the "IssuedTokenOverTransport" in the interop document. Is the client supposed to sign the SAML token and SOAP payload with the key from the SAML token? If this is the intent, it should be made clear in the text. Or is the intent to use a SAML bearer token? This is a legitimate use-case we would like to see captured in some interop scenario. If that is the intent, we need to ensure that the SAML token returned by STS is a bearer token. This should be made clear in the text. Need to understand intent of the author; I can then propose changes (if needed). ws-trust ws-sc interop editorial Prateek Mishra Marc Goodner Gudge suggested that this is a holder of key scenario. Prateek suggested this could be explained in the scenario text (in the interop document). Proposal 1 accepted on March 15th TC call. See AI-2006-03-15-02. Revised interop scenarios draft with change available for review. Moved to Closed at May 10th TC call. AI-2006-03-15-02 AI-2006-03-29-04 Appendix A states that Binding Assertions can only have Endpoint for their subject, or scope. I believe that Operation should also be allowed for the AsymmetricBindingAssertion and SymmetricBindingAssertion. We have seen situations where customers have defined different security around operations of a service, especially when building aggregate services. The constructs of the AsymmetricBindingAssertion in particular would be useful when defining security around these operations. Continuing discussion msg00080 msg00085 ws-sp spec design Tony Gullotta Tony Gullotta Add AsymmetricBindingAssertion and SymmetricBindingAssertion to section A.2. Proposal 5 accepted on May 31st TC call. Revision 7 of SP contains resolution for review. Accepted edits as applied. During some interop testing it was discovered that the spec is not clear that [Algorithm Suite] applies to message level cryptography and NOT transport-level cryptography when used in a Transport Binding. ws-sp spec editorial Martin Gudgin Editors Proposal 1 amended as follows and accepted on March 15th TC call. Amendment to proposal 1: add text explaining the reason for this is that transport protocol (IPSEC and SSL) already have techniques for selecting the algorithm. Revision 5 of SP contains resolution for review. Moved to Closed at April 4th F2F. Section 4 states, of Protection Assertions; "These assertions SHOULD apply to [Message Policy Subject]." but does not explicitly disallow their applicability at [Endpoint Policy Subject] or [Operation Policy Subject] ws-sp spec editorial Martin Gudgin Editors Proposal 1 accepted on March 15th TC call. Revision 5 of SP contains resolution for review. Moved to Closed at April 4th F2F. Section 5.2 defines a [Derived Keys] property and Section 5.3 defines an sp:RequireDerivedKeys assertion that populates that property. Although WS-SecureConversation allows for two serialized forms of derived keys; implicit and explicit, WS-SecurityPolicy does not provide a mechanism to constrain derived keys to one or the other form. ws-sp spec design Martin Gudgin Martin Gudgin Proposal 1 accepted at April 5th F2F. Editor version with resolution applied available for review. Moved to Closed at May 3rd TC call. There are occasions where efficiency is important. Reducing the number of messages in a message exchange pattern can greatly improve efficiency. One way to do this in the context of WS-Trust is to avoid repeated round-trips for multiple related token requests. An example is requesting an identity token as well as tokens that offer other claims in a single operation. ws-trust spec design Frederick Hirsch Frederick Hirsch Edits from F2F discussion to proposal 1 Proposal 2 accepted at April 4 F2F. Also result of AI-2006-04-04-02 from April 4/5 F2F minutes. Revision 5 of Trust contains resolution for review. Moved to Closed at April 26th TC call. SecureConversationToken has BootstrapPolicy which is used to secure the SecureConversation protocol messages. How are the Signed(Parts/Elements)/Encrypted(Parts/Elements)that are to be secured using the Bootstrap policy obtained . Are they implicit. ws-sp spec design Venu Venu Proposal 1 accepted on April 19th TC Call. Editor version with resolution applied available for review. Moved to Closed at May 3rd TC call. How is SignatureProtection property(EncryptSignature assertion ) and its scope different from TokenProtection property ?. When SignatureProtection property is true how should one treat Signature elements belonging to SignedSupportingTokens/ SignedEndorsingSupportingTokens/EndorsingSupportingTokens . ws-sp spec design Venu Venu Closed with no action as TC determined no changes required to spec at April 5th F2F. What does it mean when we have X509Token( with RequireDerivedKeys assertion) under Initiator Token and Recipient Token of AsymmetricBinding. How are the keys derived when this is the policy configuration. Trying to apply lines 795 and 796 apply here, should one generate two symmetric keys one for Initiator Token and Recipient Token, both encrypted for the recipient ?. If the above is true then is the statement "encrypted with the key material associated with the token." on line 796 correct?. Eg: The Key associated with InitiatorToken on the client side is a client certificate and not the recipient certificate. ws-sp spec design Venu Venu Closed with no action on June 7th TC call. AI-2006-05-03-01 The WS-Trust specification defines a <wst:KeyType> element that allows the requestor to express the type of key desired in the issued security token. Currenly, WS-Trust specification defines two key types: * public key * symmetric key This issue proposes to add a third key type - a NoProofKey. This key type can be used by requestors to indicate that they want a security token to be issued without any key material to proof the possession of the issued security token. ws-trust spec design Jan Alexander Jan Alexander Proposal 1 revised at April 4 F2F, see minutes. Proposal 2 accepted at April 4th F2F. Revision 5 of Trust contains resolution for review. Moved to Closed at April 26th TC call. Make the final protocol leg always be an RSTRC (rather than either an RSTR or an RSTRC as it is currently). So the protocol becomes; RST, RSTR*, RSTRC. Currently a STS can use either RSTR or RSTRC to return the issued token(s) to the requestor. Even in the simplest case when a requestor ask for a token and STS immediately responds with a issued token in the reply, the requestor must be prepared to process both RSTR and RSTRC style responses because STS can use RSTRC even for a single token. This change makes the protocol easier to reason about and easier to implement because a requestor knows that the issued token will be always returned using RSTRC style response. ws-trust ws-sc spec design Jan Alexander Jan Alexander Proposal 1 revised at April 4 F2F, see minutes. Proposal 2 accepted at April 4th F2F. Revision 5 of Trust contains resolution for review. Moved to Closed at April 26th TC call. Revision 6 of SC contains resolution for review. Accepted edits as applied for SC. i059 Add a wst:ValidateTarget element to the RST of the validate binding. This provides a determinisitic way of identifying the token that requires validation. Currently there is element defined that points to a security token that the requestor wants to be validated. We have wst:CancelTarget, wst:RenewTarget but we currently don't have wst:ValidateTarget. This proposal aligns the Validate binding request format with other bindings' request formats. ws-trust spec design Jan Alexander Jan Alexander Proposal 1 accepted at April 4th F2F. Revision 5 of Trust contains resolution for review. Moved to Closed at April 26th TC call. i034 Make the WS-Addressing action of the final protocol message distinct from that of intermediate message used for negotiation. Currently it is not possible to distinguish messages sent during the negotiation phase from the final message in the conversation without looking at the message body content of every message. The final message is different than the intermediary messages because it always carries the issued token that the requestor asked for in the initial RST message. The requestor might want to process the last message differently than the intermediary messages. Using a distinct WS-Addressing action helps to do that. ws-trust spec wsdl design Jan Alexander Jan Alexander Proposal 1 accepted at April 4th F2F. Revision 5 of Trust contains resolution for review. Moved to Closed at April 26th TC call. i057 Currently the WS-Trust spec does not provide a way for a STS to initiate the security token cancellation. Only the client is able to cancel the security token by sending a RST/Cancel message to the STS as described by the Cancel binding in section 6. This issue proposes to add a new option binding to the WS-Trust specification that will enable STS to cancel the security token by sending a one-way message to the client endpoint. This binding can be used only when the client has an addressable endpoint that the STS can use to send a one-way message to the client. ws-trust spec design Jan Alexander Jan Alexander Proposal 1 accepted at April 4th F2F. Note AI-2006-04-04-06 Revision 5 of Trust contains resolution for review. Moved to Closed at April 26th TC call. The section 7.3 describes how to use a shortcut mechanism to derive keys using security token reference. This issue proposes to add a wsc:Length attribute description to this section to define the length of the derived key. The reason for adding @wsc:Length is to allow sender to specify the length of the derived key for the recipient. Currently there is no way how to pass this information for implied derived keys. Additionally, no default value is currently defined for the implied derived key mechanism. ws-sc spec design Jan Alexander Jan Alexander Proposal 1 accepted at April 4th F2F. Revision 5 of SC contains resolution for review. Moved to Closed at April 26th TC call. Provide information on where the UML generated schema might be more restrictive than the SP schema when the SP spec reaches a more stable point. ws-trust schema editorial AI-2006-03-22-01 Tony Nadalin There are three minor problems in the WS-SecurityPolicy schema XSD file, oasis-wssx-ws-securitypolicy-1.0.xsd , version 2, http://www.oasis-open.org/apps/org/workgroup/ws-sx/document.php?document_id=16373. ws-sp schema editorial Symon Chang Editors Proposal 1 accepted at April 5th F2F. Editor version of schema with resolution applied available for review. Accepted edits as applied. AI-2006-05-03-05 Should SecureConversation support batch semantics as created by Issue 52? ws-sc spec design F2F discussion of issue 52 Tony Nadalin No use case. Will reopen if one is presented. AI-2006-04-05-03 Permitting requestors to avoid recieving cancel messages ws-trust spec design F2F discussion of i060 Tony and Jan Proposal 1 accepeted at May 10th TC call. Revision 8 of Trust contains resolution for review. Accepted edits as applied. i060 AI-2006-05-03-02 SecurityPolicy use cases ws-sp spec design Ashok Malhotra Ashok Malhotra When a service has more than one SecureConversationToken defined in a policy and if the Issuer is absent, then when a client sends a RST to the service for SignatureToken how will the service know if the request is for SignatureToken or Encryption Token. IMO RST does not have such information, it gets complicated for the service to pick the right bootstrap policy to verify the incoming message. I have attached a sample policy file to describe the problem. Appreciate if the spec recommends proper usage of SecureConversationToken and provides an ability to identify the tokens when multiple of them are allowed in the policy. ws-sp spec design Venu Venu Closed with no action per AI-2006-05-03-03 on July 19th TC call. AI-2006-05-03-03 Raised as result of AI-2006-04-04-06. ws-trust spec design AI-2006-04-04-06 Editors Proposal 1 accepted on Apr 26th TC call. Editor version with resolution applied available for review. Accepted edits as applied. AI-2006-05-03-04 WS-SecurityPolicy specifies default nested policy assertions and from policy intersection perspective, these assertions must be explicitly stated to avoid false negatives. ws-sp spec editorial Tony Nadalin Tony Nadalin Proposal 1 accepted on May 17th TC call. Revision 7 of SP contains resolution for review. Accepted edits as applied. Section 11 of the WS-SecurityPolicy draft provides clear guidance on extending existing policy assertions or defining new ones. However, the policy assertion matching rules (Section 3.1.3) raise some questions about the use of assertions with extensions, specifically lines 364-365: [quote] An assertion with an empty nested policy does not intersect with the same assertion without nested policy. [quote] If a server offered a service with policy expression: <sp:SupportingToken> <wsp:Policy> <sp:UserNameToken/> </wsp:Policy> <sp:SupportingToken> and the client policy includes nested policy assertion <orcl:IncludesPassword=""> as in: <sp:SupportingToken> <wsp:Policy> <sp:UserNameToken> <wsp:Policy> <orcl:IncludesPassword> </wsp:Password> </wsp:Policy> <sp:SupportingToken> Then should not the two policy expressions match? As things stand, the two expressions will not match even though the client is fully able to satisfy the server's expectations. ws-sp spec design Prateek Mishra Prateek Mishra Closed with no action on July 19th TC call per following: Decision to raise within WS-Policy. Request to WS-Policy WG to provide section number with stable fragment ids we can use Note, section 3.1 also removed per previous issue The only place in WS_SecurityPolicy which seems to address exactly what WS-SP is supposed to be used for is section 1. Currently it says: "WS-Policy defines a framework for allowing web services to express their constraints and requirements. [...] This document takes the approach of defining a base set of assertions that describe how messages are to be secured. [...] The intent is to provide enough information for compatibility and interoperability to be determined by web service participants along with all information necessary to actually enable a participant to engage in a secure exchange of messages." This seems to leave a lot of questions unanswered. Is a consumer required to use SP? Is SP suitable for expressing a Consumer's policy? Does an SP represent an enforceable access control policy? Can a Web Service reject messages which conform to its policy? It seems to me desirable that the spec provide more specific guidance on what is expected. ws-sp spec editorial Hal Lockhart Hal Lockhart Proposal 2 ammended with "for example because a client certificate has expired" to "for example because a client certificate has been revoked" and accepted on June 21st TC call. Currently there is no way how to indicate KeyWrapAlgorithm requirement in the RST if the STS uses asymmetric key to protect the issued token for the relying party. This issue proposes this additional optional parameter to be added to the section 9.2 ws-trust spec schema design Jan Alexander Editors Proposal 1 accepted on June 7th TC call. Revision 8 of Trust contains resolution for review. Accepted edits as applied. Currently, the section 9.2 in WS-Trust specification defines various elements that can be used to request specific types of keys or algorithms for the returned token and the RSTRC message. The current description of some of those parameters is not clear enough for the reader to understand how they affect the issued token and the returned RSTRC message. This issue proposes an additional description to clarify those parameters. This issue already depends on the other issue that is being raised that proposes to add a new optional parameter to the RST - KeyWrapAlgorithm. (Issue 72) ws-trust spec design Jan Alexander Proposal 1 accepted on June 7th TC call. Revision 8 of Trust contains resolution for review. Accepted edits as applied. i072 There are many security contexts in which supporting tokens in (a)symmteric bindings are required to be encrypted. Typically, the supporting token is a username, saml or proprietary token but other possibilities also exist. This note proposes the addition of an <EncryptSupportingToken> element to symm. and asymm. bindings within ws-sp. ws-sp spec design Prateek Mishra Prateek Mishra Proposal 1 accepted on June 21st TC call. We don't have a way in WS-SP to express HTTP authentication modes beyond 'use client certs' and 'don't use client certs'. It would probably behoove us to define nested assertions that would live inside sp:HttpsToken. ws-sp spec design Marc Goodner Marc Goodner Proposal 1 accepted on June 14th TC call. Revision 7 of SP contains resolution for review. Accepted edits as applied. This issue concerns the following use-case: a requestor wishes to participate in a multi-message session with a recipient. The requestor acquires a SC token by some means from its local security system and adds it to the security header of a SOAP message. The SOAP message is meant to initiate a sequence of exchanges with the recipient, all of which are to be protected by the SC token. Notice that in general, the SOAP message may carry several security headers including other security tokens. How can the requestor indicate to the recipient that a specific SC token is to be used for the session? ws-sc spec design Prateek Mishra Prateek Mishra Closed with no action on June 28th TC call. There is already material in SC to use a freestanding RSTR in the response. Remaining part of issue is now documented in issue 77. i077 In many application processing protocols, there is a need to correlate security tokens with certain application messages. For example, there may be an expectation that a specific key is available when a certain message is processed. To deal with this requirement, we need some means of "connecting" one or more security tokens with an application message. Section 8 of WS-SC describes one solution to this problem. It suggests that application message itself can include a STR referring to a secuity token. While this solves the problem it does so at the cost of propagating knowledge of WSS schema (and version) to every application protocol that uses this technique. This is a very intrusive solution with a high cost in complexity. ws-sc spec design Prateek Mishra Prateek Mishra Chapter 8 says that a STR may be used to reference an SCT, but does not specify what reference types may be used as was done in the WSS Token Profiles. In particular there are use cases for referencing an SCT by its wsc:Identifier value. The example in Chapter 8 shows a reference being made using a wsu:Id, but the text does not really specify what is allowed or not allowed. For example, can an Absolute URI be used or only a relative one. There are a number of usecases where it would be desirable to reference an SCT by its wsc:Identifier value. 1. When the SCT is only conveyed in the first message, especially if there is more than one context active. 2. When reference is made from the Body or other Header element to the SCT it is desirable to have a message-independent means of referencing the SCT. ws-sc spec design Hal Lockhart Hal Lockhart i076 The SecurityPolicy spec does not clearly state if Bootstrap policy is to be treated as a PolicyAssertion and should it be considered for policy normalization ?. If BootstrapPolicy is a PolicyAssertion , I would request it to be added to Appendix A . ws-sp spec editorial Venu Venu Direct editors to add bootstrap policy to appendix a Proposal 2 accepted on July 19th TC call. It is not clear from the spec on how EncryptParts specified under supportingtokens need to be secured. eg : If the X509Token present under a SupportingToken is that of the sender , how can it be used to encrypt the message parts identified by EncryptParts/Elements that are specified under the supporting token. see mail for example ws-sp spec design Venu Venu Proposal 1 accepted on July 19th TC call. Policy statements will not successfully intersect if one has a nested policy statement and the other does not. This means that if one message participant wishes to accept all variations of an assertion, and the other specifies only one variant, it is necessary for the first to explicitly list all variations rather than none. This can be cumbersome and can have a negative impact on adoption, and interoperability if done incorrectly. WS-SX should provide common set of referenced security assertions and associated URIs. ws-sp policy design Frederick Hirsch Frederick Hirsch two identical references with different tags: [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, Harvard University, March 1997 Keep first, more descriptive. Replace any KEYWORDS references with RFC2119 references in document. ws-sp spec editorial Frederick Hirsch Editors See description Proposal 1 accepted on July 12th TC call. The shading in the figures obscures the text and makes the figures harder to read, without adding value. Remove the shading from the figures. In particular at lines 2630, 2914, 3064. If possible make these figures slightly larger. ws-sp spec editorial Frederick Hirsch Editors Remove the shading from the figures at lines 2630, 2914, 3064. If possible make these figures slightly larger. Proposal 1 accepted on July 12th TC call. The specification states at line 352: "Assertions MUST specify whether or not they contain nested policy." However most of the policy examples in the document do not do so. (Only the example on this topic at line 340 does) Either this statement should be removed or the examples updated. This may be an issue with the stability of WS-Policy. Policy statements in particular: lines 21, 295, 318, 381, 406, 438, 467, 503, 3177 ws-sp spec design Frederick Hirsch Editors Remove statement at line 352, no longer required in WS-Policy submission to W3C. Also remove example at line 340 and appropriate text. Proposal 1 accepted on July 12th TC call. At line 111, "specifications requiring such an ID or timestamp could reference it (as is done here)" replace ID with Id ws-sp spec editorial Frederick Hirsch Editors s/such an ID or timestamp/such an Id attribute or timestamp element/ Proposal 1 accepted on July 12th TC call. Note editors to identify correct edit and notify TC. The EncryptedElements assertion requires element encryption, at line 724. There is no corresponding EncryptedContent assertion. So there is no way to require encryption of the content of an element (e.g. xenc Type xmlenc#Content), only an element itself. This could be a limitation to policy expressiveness, when element content needs to be secured but the element itself not. ws-sp spec design Frederick Hirsch Frederick Hirsch The spec states at line 372 "An assertion with an empty nested policy does not intersect with the same assertion without nested policy." This does not make sense, they both mean exactly the same thing. Perhaps this is an issue for W3C Policy group, but <assertion /> and <assertion> <policy /> </assertion> should mean the same thing? Shouldn't an engine treat them as equal? Should policy normalization process include this? ws-sp spec design Frederick Hirsch Closed with no action on July 12th TC call as there is a related issue in the W3C Policy WG. In a number of places an optional attribute is used to indicate the version of XPath to use, with the text "This optional attribute contains a URI which indicates the version of XPath to use." Would it help interoperability to define the default version of XPath to use if attribute is not stated? Places where this occurs: 646 /sp:SignedElements/@XPathVersion 725 /sp:EncryptedElements/@XPathVersion 755 /sp:RequiredElements/@XPathVersion ws-sp spec design Frederick Hirsch Editors In every instance specify default to use if no attribute specified. Xpath 1.0 (as opposed to 2.0)? Proposal 1 accepted on July 12th TC call. a) Line 214, remove comma from "The intent of representing characteristics as assertions, is so that QName matching" b) Line 249 s/protection encryption/encryption/ in "The bindings are identified primarily by the style of protection encryption used to protect the message exchange." c) Line 653 Change "Multiple instances of this element may appear within this assertion and should be treated as separate references in the signature." to "Multiple instances of this element may appear within this assertion and should be treated as separate references in a signature when WSS is used." i.e., s/.$/ when WSS is used./ (Note that SignedElements may be satisfied using transport security, in which case no special action is required if all is protected). d) line 1460, are planning on defining the AbsXPath URI in the sp namespace, or do we have a candidate namespace in mind? Remember to replace TBD. e) add at line 3545, "This section may not apply when transport level security is applied." (or more generally, clarify what is required when transport security used - ie endorsing signatures) f) Remove Section F at line 3601. Stated earlier in document what is non-normative. ws-sp spec editorial Frederick Hirsch Editors See description Nits to original proposal Proposal 2 accepted on July 12th TC call. Rules for strict format of security element seem incorrect in the case of encrypted key used with Asymmetric Key. It is my understanding that for every encryption, there will either be a ReferenceList (for Symmetric) or an EncryptedKey (for Asymmetric). However, the rules seem to require a tope level ReferenceList even when an EncryptedKey is present. This causes implementation problems, especially for WSS 1.0. Section 6.7.1 (lines 1528-1536) say: ---- 4. If there are any encrypted elements in the message then a top level xenc:ReferenceList element MUST be present in the security header. The xenc:ReferenceList MUST occur before any xenc:EncryptedData elements in the security header that are referenced from the reference list. However, the xenc:ReferenceList is not required to appear before independently encrypted tokens such as the xenc:EncryptedKey token as defined in WSS. 5. An xenc:EncryptedKey element without an internal reference list [WSS: SOAP Message Security 1.1] MUST obey rule (1). An xenc:EncryptedKey element with an internal reference list MUST additionally obey rule (4). ---- But my understanding is that you use either an EncryptedKey or a ReferenceList, but not both. If this is not a simple error, but intentional, I will provide information about implementation difficulties. ws-sp spec editorial Hal Lockhart Hal Lockhart Change #4 to say ReferenceList or Encrypted Key. AI-2006-07-12-02 See message. ws-sp spec editorial Frederick Hirsch Frederick Hirsch Opened to catch resolution to AI-2006-04-04-03 ws-sp spec design TC discussion Editors Proposal 1 accepted on July 19th TC call. AI-2006-04-04-03 i052 When listing the assertions within any of the SupportingTokens assertion types, the token(s) to use are placed at the same level as the other assertions describing the SupportingTokens assertion. See message for complete description ws-sp spec design TC discussion Editors WS-SecurityPolicy uses the word "domain" in several places. For example, in Section 3.1.3 bullet 4: "Assertions from one domain MUST NOT be nested inside assertions from another domain." ... ws-sp spec design TC discussion Editors Done Done Done Done Done Due to start on March 1st. Done Done Decided this was moot at April 4th F2F Done Done Done There will no interop at the April F2F. The F2F meeting will be Tue-Wed Apr 4-5. Tony and Kelvin will provided F2F logistics information. Done Done Done They are available from the URI http://docs.oasis-open.org/ws-sx/issues/ Done Done at April F2F, see minutes. Done Jan's message DONE. See: http://lists.oasis-open.org/archives/ws-sx/200603/msg00044.html http://lists.oasis-open.org/archives/ws-sx/200603/msg00050.html New proposal for issue 16: http://lists.oasis-open.org/archives/ws-sx/200603/msg00103.html New proposal for issue 18: http://lists.oasis-open.org/archives/ws-sx/200603/msg00104.html Done Done DONE. See resolution from March 22nd minutes Done Done Done Done Done Opened issue 62 to track this action. DONE. See: http://lists.oasis-open.org/archives/ws-sx/200604/msg00025.html Done Done Done Done done Conclusion is there are no issues. Trust already has a place to put the relative piece of information and SP allows that to be specified. Done No issues found. Closed with no action. Done. Logged as issue 68. Done In progress, most message flows and XML examples are present in current draft. Done Done For symmetry it would probably be OK, however there don't seem to be any strong requirements for this. Suggest closing with no action. First week of October in San Jose hosted by BEA. done done done done See msg done Kelvin and others addressed these problems with OASIS staff. SPAM overwhelmed system last week and OASIS is working on it.