http://docs.oasis-open.org/ws-sx/issues/ Date: 2007/10/17 Revision: 82 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 Proposal 1 accepted on August 23rd TC call. Status changed to Review on August 30th TC call. Status changed to Closed on Sept. 6th TC call. 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 Status changed to Pending on Sept. 6th TC call. Status changed to Review on Sept. 6th. Edits applied in SC CD01, Trust CD01, and SP ED01-r09. Status changed to closed on Sept. 13th TC call. 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:msg00016msg00044msg00050 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.wsdloasis-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 discussionmsg00081msg00083 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 discussionmsg00071msg00082 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 discussionmsg00080msg00085 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. sp schema editorial AI-2006-03-22-01 CLosed with no action. 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 examples spec design Ashok Malhotra Ashok Malhotra Updated from original proposal. Closed Closed in Nov 29th TC meeting. Updates to the Examples document shoudl be submitted as new issues. 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. Status changed to Review on August 30th TC call. Status changed to Closed on Sept. 6th 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 2 accepted on June 21st TC call. Status changed to Review on August 30th TC call. Status changed to Closed on Sept. 6th 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 Closed with no action on August 2nd TC call. 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 Original proposal. Proposal 2 accepted, moved to pending and assigned to editors on Aug. 16th TC call. Status changed to Review on August 30th TC call. Status changed to Closed on Sept. 6th TC call. 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. Status changed to Review on August 30th TC call. Status changed to Closed on Sept. 6th 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. Status changed to Review on August 30th TC call. Status changed to Closed on Sept. 6th 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. examples policy design Frederick Hirsch Frederick Hirsch Closed with no action on Nov 29th TC call. i066 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. Status changed to Review on August 30th TC call. Status changed to Closed on Sept. 6th 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. Edits applied in r10 of SP. Status changed to Closed on Oct. 11th 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. Status changed to Review on August 30th TC call. Status changed to Closed on Sept. 6th 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. Status changed to Review on August 30th TC call. Status changed to Closed on Sept. 6th TC call. 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 Proposal 1 accepted on September 20th TC call. Edits applied in r10 of SP. Status changed to Closed on Oct. 11th TC call. 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. Status changed to Review on August 30th TC call. Status changed to Closed on Sept. 6th 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. Status changed to Review on August 30th TC call. Status changed to Closed on Sept. 6th 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 design Hal Lockhart Hal Lockhart Change #4 to say ReferenceList or Encrypted Key. remove the words 'top level' from line 1503 Proposal 4 acceped on Nov. 1st TC call. Closed on Nov 29th TC call AI-2006-07-12-02 See message. ws-sp spec editorial Frederick Hirsch Frederick Hirsch Proposal 1 accepted on July 26th TC call. Status changed to Review on August 30th TC call. Status changed to Closed on Sept. 6th TC call. 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. Status changed to Review on August 30th TC call. Status changed to Closed on Sept. 6th 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 Tony Gullotta Tony Gullotta Closed with no action on August 2nd TC call based on this rationale. 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 Ashok Malhotra Ashok Malhotra Agreed to remove statement citing domain (in description of issue) on August 9th TC call. Status changed to Review on August 30th TC call. Status changed to Closed on Sept. 6th TC call. Currently the description of the nested assertions in WS-SP reads something like; "This optional element indicates that ..." Some people have expressed confusion over whether such things are policy assertions or just elements. ws-sp spec design Martin Gudgin Martin Gudgin Proposal 1 accepted on July 26th TC call. Status changed to Review on August 30th TC call. Status changed to Closed on Sept. 6th TC call. As we've mentioned in the calls several time, some assertions are missing from Appendix A. ws-sp spec design Martin Gudgin Martin Gudgin Status changed to Pending on Oct 4th TC call. Edits applied in r10 of SP. Status changed to Closed on Oct. 11th TC call. Line 691-693 under /EncryptedParts/Header: "Such encryption will encrypt such elements using WSS 1.1 Encrypted Headers. As such, if WSS 1.1 Encrypted Headers are not supported by a service, then headers cannot be encrypted using message level security." Does this mean ws-sp prohibits the encryption of headers using WSS 1.0? Or does this mean that *if* you're using WSS 1.1 you have to use EncryptedHeader? If the latter is the case, can /EncryptedParts/Header still be used to specify header encryption for WSS 1.0, or should EncryptedElements be used? ws-sp spec design Corinna Witt Proposal 1 accepted on August 2nd TC call. Status changed to Review on August 30th TC call. Status changed to Closed on Sept. 6th TC call. 1. Line 605-607 about /SignedParts/Body say "...the entire body, that is the soap:Body element, it's attributes and content, of the message needs to be integrity protected". Line 608-618 about /SignedParts/Header don't say anything about whether the entire header needs to be integrity protected. 2. Compare line 1796-1798 about /SymmetricBinding/Policy/OnlySignEntireHeadersAndBody "This assertion indicates that the [Entire Header And Body Signatures] property is set to 'true'." with line 1499-1500 from 6.6 [Entire Header and Body Signatures] Property: "The default value for this property is 'false'." (same thing in asymmetric binding btw.) 3. Assuming both SignedParts/Body and SignedParts/Headers are 'entire element' by default and OnlySignEntireHeadersAndBody is true by default, why do we need another assertion with the same default? 4. It seems like a limitation to switch the default for 'entire element integrity protection' for headers and body wholesale - even more so if they turn out not to have the same default. ws-sp spec design Corinna Witt Proposal 1 accepted on August 2nd TC call. Agreed to opening new issue(s) if needed for parts of the issue that Gudge suggested there was no need to address. Status changed to Review on August 30th TC call. Status changed to Closed on Sept. 6th TC call. WS-Trust (section 4.4) defines a <wst:IssuedTokens> element to be used to contain tokens referenced by an RST or RSTR and also some other protocol. I am not entirely convinced that this is all that useful, but I notice that it is NOT used by WS-SecureConversation. It seems like it should be or should be dropped from WS-Trust. Presumably having a top level SOAP header element to contain tokens make it easier to find them. It is not clear this has any benefit over putting then in the <wsse:Security> element. However, if it is a good idea, the WS-SC should use it as well. If it is used, the MustUnderstand semantics of it should be described as it is a top level element in the SOAP header. ws-sc ws-trust spec design Hal Lockhart Hal Lockhart a) Drop <wst:IssuedTokens> from WS-Trust. b) Add <wst:IssuedTokens> to WS-SC. Provide Rationale. Describe MustUnderstand semantics in both specs. Closed with no action on August 23rd TC call. i078 WS-SC defines 4 operations: Issue, Amend, Renew and Cancel. In the case of Amend, WS-SC does not specify what Authentication is required. In the case of Renew, it says the original claims must be re-authenticated. If the SCT has expired, its key must not be used to authenticate. The examples for Amend and Renew both show signatures which use both the long term Token and the SCT. In the case of Cancel, WS-SC says that the client must provide PoP of the SCT secret. The example shows only one signature, which uses the SCT. It is not clear a) the reason for these choices and b) why they are all different. For Amend and Renew, it seems to me that the Principle of Perfect Forward Secrecy suggests that the long term Identity be used in all these cases to authenticate the client. That way if the SCT secret is compromised, the request will still be protected. (If the long term secret is compromised, all bets are off anyway.) Also I don't understand why a Cancel requires specifically PoP of the SCT secret. ws-sc spec design Hal Lockhart Hal Lockhart Proposal 1 accepted and status changed to Review on Sept. 6th TC call. Edits were applied in SC ED01-r09 and are reflected in CD01. Status changed to closed on Sept. 13th TC call. i078 Comparable to the level of granularity defined for UsernameToken Assertions (lines 854-861 (NoPassword, HashPassword)) and X509Token Assertions (lines 1004-1024 several token types), the SamlToken Assertion needs token types of sender-vouches and holder-of-key defined. As in the Username and X509 token cases, the WS 1.0 and WS 1.1 Saml Token profiles identify these token types as explicit use cases that the profile supports. http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf see line 495 http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf see line 672 examples spec design Rich Levinson Rich Levinson Add the following lines after line 1322 in section 5.3.8: /sp:SamlToken/wsp:Policy/sp:WssSamlHolderOfKey This optional element identifies that a SAML holder-of-key token should be used as defined in [WSS: SAML Token Profile 1.0, 1.1]. /sp:SamlToken/wsp:Policy/sp:WssSamlSenderVouches This optional element identifies that a SAML sender-vouches token should be used as defined in [WSS: SAML Token Profile 1.0, 1.1]. The above proposal would require 2 elements to fully define the required token. An alternative approach would be to explicitly define the 2 tokens for all 3 supported versions as follows: /sp:SamlToken/wsp:Policy/sp:WssSamlV11Token10HolderOfKey This optional element identifies that a SAML Version 1.1 holder-of-key token should be used as defined in [WSS: SAML Token Profile 1.0]. /sp:SamlToken/wsp:Policy/sp:WssSamlV11Token10SenderVouches This optional element identifies that a SAML Version 1.1 sender-vouches token should be used as defined in [WSS: SAML Token Profile 1.0]. /sp:SamlToken/wsp:Policy/sp:WssSamlV11Token11HolderOfKey This optional element identifies that a SAML Version 1.1 holder-of-key token should be used as defined in [WSS: SAML Token Profile 1.1]. /sp:SamlToken/wsp:Policy/sp:WssSamlV11Token11SenderVouches This optional element identifies that a SAML Version 1.1 sender-vouches token should be used as defined in [WSS: SAML Token Profile 1.1]. /sp:SamlToken/wsp:Policy/sp:WssSamlV20Token11HolderOfKey This optional element identifies that a SAML Version 2.0 holder-of-key token should be used as defined in [WSS: SAML Token Profile 1.1]. /sp:SamlToken/wsp:Policy/sp:WssSamlV20Token11SenderVouches This optional element identifies that a SAML Version 2.0 sender-vouches token should be used as defined in [WSS: SAML Token Profile 1.1]. Updated from original proposal. Status changed to Review on Nov. 1st TC call. See section 2.3 in examples document for issue 66. Closed on Nov 29th TC call. i078 i066 Ease ability to discuss, reference, review and comment on interop document. interop interop editorial Frederick Hirsch Add section numbers and line numbers to interop document Proposal accepted, applied by editors in this draft. Edits accepted and status changed to closed on August 23rd TC call. Replace "responds with a RSTR message with a SAML bearer token" with "responds with a RSTR within an RSTRC message with a SAML bearer token" interop interop editorial Frederick Hirsch Replace "responds with a RSTR message with a SAML bearer token" with "responds with a RSTR within an RSTRC message with a SAML bearer token" Proposal accepted, moved to pending and assigned to editors on Aug. 16th TC call. Changes reflected in rev 07 of interop doc, status changed to Review. Status changed to closed. Update interop documents to reflect what was actually tested. interop interop editorial Tony Nadalin Editors Seems the interop documents don't reflect in all cases what was actually tested (XML) Proposal 1 accepted, reflected in rev 07 of interop doc, status changed to Review. Status changed to closed. WS-SecureConversation mentions the following on using label while computing deriving keys, /wsc:DerivedKeyToken/wsc:Label If specified, this optional element defines a label that is used in the key derivation function for this derived key. If this isn't specified, it is assumed that the recipient knows the label to use. The string content of this element is UTF-8 encoded to obtain the label used in key derivation. Note that once a label is used for a derivation sequence, the same label SHOULD be used for all subsequent derivations. It also specifies, The label is the concatenation of the client's label and the service's label. These labels can be discovered in each party's policy (or specifically within a <wsc:DerivedKeyToken> token). Labels are processed as UTF-8 encoded octets. If either isn't specified in the policy, then a default value of "WS-SecureConversation" (represented as UTF-8 octets) is used. When a label is specified it is not clear if you should simply use it or concatenate your own label together with it. It seems that when a value is specified it makes more sense to simply use it than apply the concatenation rule. There also is nothing in SecurityPolicy that would allow the discovery of the other party’s label if it was not sent in the wsc:DerivedKeyToken. So the concatenation rule doesn’t seem feasible. However, current products do use that rule making the normal default value “WS-SecureConversationWS-SecureConversation”. ws-sc spec editorial Marc Goodner Proposal 1 accepted on August 23rd TC call. Status changed to Review on August 30th TC call. Status changed to Closed on Sept. 6th TC call. Since a <IssuedTokens> element may need to contain Tokens issued as the result of multiple requests, why is it not allowed to contain a <RequestSecurityTokenResponseCollection> element? ws-trust spec schema design Hal Lockhart Closed with no action on August 23rd TC call as IssuedTokens is semantically an RSTRC The WS-T and WS-SC Schemas contain comments saying "Actual content model is non-deterministic, hence wildcard. The following shows intended content model:" However in the WS-SP Schema the comment has morphed into "Accurate content model is nondeterministic". (in 5 places) I assume the latter is a typo and should be fixed to match WS-SC and WS-T. ws-sp schema editorial Hal Lockhart Fix 5 comments in WS-SP Schema file to match WS-SC and WS-T Schemas. Proposal 1 accepted on August 30th TC call. Status changed to Review on Sept. 06, edits available in updated schema. Status changed to closed on Sept. 13th TC call. When requestor inserts parameters into an RST request which come from a third party – for example relying party policy – there is a potential for an attack. Currently both requestor RST parameters and third party RST parameters are mixed together as a direct children of the wst:RequestSecurityToken element. This prevents STS to differentiate the RST parameters based on their source. This means that both kinds of RST parameters are trusted in the same way by the STS. This can open a potential attack vector because the third party is given control over the content of the RST message that the requestor sends to the STS and the STS cannot detect which parameters came from which source in order to determine how much it should trust a particular RST parameter. To mitigate the attack the RST should differentiate between parameters originated by the requestor and parameters not originated by the requestor. ws-trust spec design Jan Alexander Jan Alexander Proposal 1 accepted and status changed to Review on Sept. 6th TC call. Edits were applied in Trust ED01-r11 and are reflected in CD01. Status changed to closed on Sept. 13th TC call. i109 The RequestSecurityTokenTemplate parameter of the IssuedToken assertion is critical to allow generalized token issuance policy, but allows possible RST parameter attacks because the requestor's parameters cannot be separated from those specified for the target site. See the description of the attack in the related WS-Trust issue description. ws-sp spec design Jan Alexander Jan Alexander Proposal 1 accepted and status changed to Review on Sept. 6th TC call. Edits were applied in SP ED01-r09. Status changed to closed on Sept. 13th TC call. i108 Security Policy specification should support specifying mandatory Header elements using LocalName and NamespaceURI. This will help implementations that want to avoid use of XPath where ever possible. ws-sp spec design Venu Venu Expanded from original proposal. Proposal 1 accepted, status changed to pending. Edits applied in r10 of SP. Status changed to Closed on Oct. 11th TC call. How can one find the security policy applicable to secure the message exchange in obtaining the token from the specified issuer? Is it using the issuer's WSDL? In the case of the SecureConversationToken, can we use the BootstrapPolicy as the security policy applicable to the message exchange with the issuer in the case where there's an Issuer specified? ws-sp spec design Ruchith Fernando Closed with no action on August 30th TC call. Is it possible to use WS-SecurityPolicy to specify the case where the SCT is created by one of the communicating parties and sent in an unsolicited RSTR(C?) message? should and how do we indicate who creates the SCT? ws-sp spec design Ruchith Fernando Closed with no action on August 30th TC call. Section 3 needs update to include RSTRC (line 277 of version 06) ws-sc spec design Ruchith Fernando Add the RSTRC Proposal 1 accepted on August 30th TC call. Proposal 1 accepted and status changed to Review on Sept. 6th TC call. Edits were applied in SC ED01-r09 and are reflected in CD01. Status changed to closed on Sept. 13th TC call. Additional algorithm properties, assertions and references needed ws-sp spec design Frederick Hirsch Frederick Hirsch Proposal 2 accepted on October 25th TC call. Closed on Nov 29th TC call. Appendix D, Section D.4 is "Elements that are encrypted" 3. says "Any wsse:UsernameToken when a transport binding is NOT being used." This seems wrong on several counts. Presumably the intent is to protect a cleartext password. 1. It makes no sense to routinely encrypt the Username and has negative effects in some cases. 2. When a hashed password is used it makes no sense to routinely encrypt the password. 3. When there is no password or password derivation is used, there is no password present and it makes no sense to routinely encrypt what is present. 4. When a UsernameToken is used as a supporting token to indicate a proxied identity in conjunction with a signing token, (see for example the WS-I Sample Apps) then it is critical that the signature include the Username, but encrypting it still makes no sense and may cause problems. Note that I am not suggesting we prohibit encrypting these things, just that encryption should not be the default. Encryption of anything in the Security header can still be specified with a EncryptedElements assertion. Finally, if this section is intended to be normative (see my next issue) then it should use the RFC 2119 keywords rather than a phrase like "Elements that are encrypted". ws-sp spec design Hal Lockhart Hal Lockhart Proposal 2 accepted on Nov. 1 TC call. Closed on Nov 29th TC call The last sentence of section 1 says "Section 11, all examples and all Appendices are non-normative." That suggests that Appendix D is a summary of normative information which is found elsewhere. However, I can not find any other source of the information in WS-SP. If Appendix D is non-normative, then I question why it is in the document at all. Note that Appendix A explicitly says it is non-normative, suggesting that some Appendices may be. Appendix B could conceivably be considered normative, it is hard to tell. Appendix C is examples, so it seems safe to assume they are not normative, however it might be good to say explicitly that if Appendix C conflicts with section 6.7 then 6.7 takes precedence. ws-sp spec design Hal Lockhart Marc Goodner Proposal 2 accepted on Nov. 1 TC call. Closed on Nov 29th TC call. i115 Section 8.5 SignedEncryptedSupportingTokens does not define whether to use Element Encryption or Content Encryption to encrypt the token. This will be difficult to interop with different implementations and create some confusion to the user. Section 8.6 EndorsingEncryptedSupportingTokens Assertions and Section 8.7 SignedEndorsing EncryptedSupportingToken Assertions have the same issue. ws-sp spec design Hal Lockhart Proposal 2 accepted on Nov. 1 TC call. Closed on Nov 29th TC call. The example security policy in chapter 1.1 (Example) uses a Kerberos V5 APREQ token for the ProtectionToken as follows: See the proposal for complete description. Proposed Resolution: Change the example in chapter 1.1 according to the above description. ws-sp spec design Martin Raepple Martin Raepple Proposal accepted on Nov. 29th TC call. Status changed to Pending. Status changed to closed on Dec. 6th TC call Section 2 as a whole is normative except for some parts explicitly marked as non-normative (i.e. Line 251 and 306). Line 272-274 (in Section 2) provides just non-normative information (these lines are used only to introduce non-normative WS-Federation spec). There might be cases where non-normative information is used to describe normative portion of spec. But this is not the case. I cann't guess the reason why these lines are necessary here. Proposal: Remove Line 272-274. ws-trust spec editorial Toshiro Nishimura Toshiro Nishimura Closed with no action in Nov 29th TC meeting On WS-Trust: Line 346-348,357: Duplicated description. Though L346-348 says using dateTime and UTC time is RECOMMENDED, L357 says all time references use dateTime and UTC. Remove L357, or modify L357 using "RECOMMENDED". Line 422: "recipient" would be "requestor" Line 431: change "RST" to "RSTR" Line 677,679: change "wsp:Claims" to "wst:Claims" On WS-SecureConversation: Line 537-538: I think "over the security context signature created using ..." would be "over the security context using ..." Line 819: remove "is as follows" Line 857: change "label" to "nonce" Line 779-781,883: different default value. I think L883 should be changed. (change "WS-SecureConversationWS-SecureConversation" to "WS-SecureConversation") Line 884: duplicated periods ("..") at the end of line. remove one. Line 1044: change "wsse:Security" to "wsse:Security" Proposal: As written above. ws-sc ws-trust spec editorial Toshiro Nishimura Toshiro Nishimura Propsoal accepted in Nov 29 TC meeting. Status changed to Pending. Status changed to closed on Dec. 6th TC call WS-Trust normatively references WS-Policy and WS-PolicyAttachment 1.2 (W3C Member Submissions) and uses some elements defined in its namespace (i.e. wsp:AppliesTo in RST and RSTR, wsp:Policy and wsp:PolicyReference in RST). WS-Policy/Attachment 1.5 is expected to be standardized near future and the elements will be defined in different namespace. What should we (WS-SX TC) do when WS-Policy/Attachment 1.5 is completed? Will we revise WS-Trust at that time? ws-trust spec editorial Toshiro Nishimura Toshiro Nishimura Closed with no action on Nov @9th TC call. Future W3C recommendations may be incorporated in a future rev of the spec. Including example messages that conform to the policy examples would make this document more effective in educating a broader audience. Proposed Resolution: In each use case include a simple message with a security header that conforms to the listed policy. Include text that highlights concepts introduced in the use case tying the message to the policy. So, for example, in the first use case that introduces the inclusion of a user name token, highlight the lines in the sample message that represents the token and reference the lines in the policy that called for it. In the first use case that introduces the inclusion of a password in the username token, identify the line with the password. The examples I've just mentioned may seem obvious, but this approach will be very useful for some of the more complex use cases later in the doc. examples spec design Tony Gullota Tony Gullota New draft of examples doc uploaded, contains two examples for review. Status changed to Pending. Updated Draft posted. Status changed to Review Closed 0n Jan 31, 2007 TC call Example 2.1.1.2 ============== In example 2.1.1.2, sp:SupportingToken should be changed to be sp:SupportingTokens (plural). In example 2.1.1.2, the SecurityPolicy schema needs to be updated with the NoPassword assertion in the UsernameToken assertion. examples spec design Anthony Nadalin Closed with no action. Example 2.1.1.3 ============== In example 2.1.1.3, sp:SupportingToken should be changed to be sp:SupportingTokens (plural). In example 2.1.1.3, sp:UserNameToken should be changed to be sp:UsernameToken (case change). In example 2.1.1.3, the text talks about a Nonce and a Timestamp, but no such elements appear in the message. In example 2.1.1.3, the SecurityPolicy schema needs to be updated with the HashPassword assertion in the UsernameToken assertion. examples spec design Anthony Nadalin Updated Draft posted. Status changed to Review Closed on 5/30/07 TC call Example 2.1.2.1 ============== In example 2.1.2.1, sp:SupportingToken should be changed to be sp:SupportingTokens (plural). examples spec design Anthony Nadalin Updated Draft posted. Status changed to Review Closed on 5/30/07 TC call Example 2.1.3 ============== In example 2.1.3, AlwaysToRecpt should be changed to be http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient. In example 2.1.3, AlwaysToRecipient should be changed to be http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient. In example 2.1.3, Never should be changed to be http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Never. examples spec design Anthony Nadalin Updated Draft posted. Status changed to Review Closed on 5/30/07 TC call Example 2.1.4 ============== In example 2.1.4, the description of the scenario says that the UsernameToken should be encrypted, but the example XML does not show this, and the policy identifies the UsernameToken as a SignedSupportingToken, not a SignedEncryptedSupportingToken. examples spec design Anthony Nadalin Updated Draft posted. Status changed to Review Closed on 5/30/07 TC call Example 2.2.1 ============== In example 2.2.1, AlwaysToRecpt should be changed to be http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient. In example 2.2.1, Never should be changed to be http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Never. In example 2.2.1, Id="WSS10Anonymous with Certificates_input_policy" should be changed to Id="WSS10Anonymous_with_Certificates_input_policy" In example 2.2.1, Id="WSS10anonymous with certs_output_policy" should be changed to Id="WSS10anonymous_with_certs_output_policy" The XML sample is missing the EncryptedKey element, which implies that the soap:Body content was encrypted with one of the asymmetric keys, which would be incorrect. Once this EncryptedKey element is added, the description will need to refer to it examples spec design Anthony Nadalin Updated Draft posted. Status changed to Review Closed on 5/30/07 TC call Trust10 is old assertion from ws-securitypolicy-1.2-spec-ed-12. The current spec has renamed Trust10 assertion into Trust13 assertion. The example 2.2.3 and 2.2.4 should be changed accordingly. This includes Lines: 1551, 1557, 1601, 1766, 1772, and 1822, to change from “Trust10” to “Trust13”. examples spec design Symon Chang Updated Draft posted. Status changed to Review Closed on 5/30/07 TC call In example 2.3.2.1, AlwaysToRecpt should be changed to be http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient. The policy specifies the SAML token to be a SignedSupportingToken, but the XML does not show that the SAML token is signed via Web Services Security. Is the XML incorrect, or should the policy have specified just SupportingToken? examples spec design Anthony Nadalin Anthony Nadalin Closed with no action Presuming that this is the right forum to post this suggestion. The UsernameTokenProfile 1.1 talks about usage of <Nonce> , the semantics of which are as follows: <wsse:UsernameToken wsu:Id="ID"> <wsse:Username> ... </wsse:Username> <wsse:Password Type="..."> ... </wsse:Password> <wsse:Nonce EncodingType="..."> ... </wsse:Nonce> <wsu:Created> ... </wsu:Created> </wsse:UsernameToken> The <Nonce>here includes a random token generated by a requestor while accessing a service. The spec says that this should be generated fresh, for service providers to detect relay attacks. However, there is nothing which guarantees the requestor, that the response generated from the service was actually for the Nonce sent by the requestor. What I mean is that, it is possible to substitute a different random value of Nonce in transit(especially in case of plaintext password), and the service provider would not be able to detect this. (Of course signing the token will integrity protect it). ws-sc ws-sp spec design Aditya Athalye This is an issue with the WSS TC specs, not the WS-SX specs. Closed with no action on May 15 '07 call. Example 2.1.1.1 ============== In example 2.1.1.1, sp:SupportingToken should be changed to be sp:SupportingTokens (plural). In example 2.1.1.1, the generated XML shows deprecated wsse:PasswordType. This should be oasis-200401-wss-username-token-profile-1.0#PasswordType examples spec design Anthony Nadalin Updated Draft posted. Status changed to Review Closed on 5/30/07 TC call The WS-Sec Policy 1.2 has provision for integrity protection of soap attachments using /signedParts/Attachments. This is what the spec says: Lines 461-462 "When SOAP Message Security is used to accomplish this, all message parts other than the part containing the primary SOAP envelope are to be integrity protected.." Simply looking at this element does not clearly indicate to a service consumer whether attachment content only or the complete attachment needs to be signed. This can especially be a problem for service providers who reject messages NOT conforming to policy, for example signing only attachment content when complete is required is a policy non-conformance. ws-sp spec design Aditya Athalye Tony Nadalin If I understand correctly, the presence of the above Attachments element inside SignedParts would mean sign all the attachments in the message (Content + MIME Headers). This translates to using the "Attachment-Complete" Signature Transform in SwA 1.1. However, in that case there doesn't seem to be any provision to indicate that only Attachment content of all attachments to be signed, and not the MIME headers. (Attachment-ContentOnly Transform). Is there a plan to add an attribute to the sp:Attachments element? We could add an optional attribute to this as: <sp:Attachments signContentOnly="true|false"> If it is absent it could mean sign the attachment contents as well as Headers, else sign content only. Assigned to Tony Nadalin. See proposal examples spec editorial Aditya Athalye Editors Assigned to Editors. Status changed to Pending. Fix applied in latest uploaded Examples document. Status changed to Review WS-SP Use cases doc states (Lines 968-969) "Line (M046) contains the Nonce element and Line (M047) contains a timestamp. These two elements should also be included in the PasswordText case for better security" The UsernameToken assertion in Security Policy supports only :<NoPassword>, and <HashPassowrd> assertion. UseCase: According to the use case document, Nonce, and Creation timestamp should be sent even for plain text passwords for better security which is a very valid requirement IMO. However, present security policy, and the schema(?) supports only HashPassword, which can indicate to the requestor, the provider's requirement for sending Password Digest, Nonce, and Created. If <HashPassword> is not present (assuming it is not <NoPassword>), it tells the requestor, that only Username, and clear text Password is mandatory. This no way indicates that the service may need a Nonce as well. So what it essentially means is that, service provider is actually offering a choice to the requestor: 1.) Send a plaintext password without Nonce/Created. (Less secure) - Acceptable to service: 2.) Send a plaintext password WITH Nonce/Created. (More Secure) - - Acceptable to service Obviously any requestor will take the less secure route to access to service. What should have happened is: Service provider unambiguously declaring its intention to check for Nonce/Created irrespective of PasswordType, and rejecting any messages which then do not conform to its policy. This leaves the requestor with only the more secure route to take. examples spec design Aditya Athalye Rich Levinson See inline in referenced document Previously discussed as issue 132 (http://docs.oasis-open.org/ws-sx/issues/Issues.xml#i132). Noted that the example document contains advice not coming from SP itself. Members need more time. Status changed to Active. Changes applied in proposal 2 accepted, status changed to review. Status changed to closed. Lines 1626-1627 : "....an X.509 token that must not be included with all messages sent between the recipient and Recipient." examples spec editorial Aditya Athalye "...an X.509 token MUST NOT be included with any message sent between Initiator and Recipient" ? Editors Assigned to Editors. Status changed to Pending. Fix applied in latest uploaded Examples document. Status changed to Review Lines 1638: Line (P042) indicates that the Issed Tokens property is set to ‘true’ examples spec editorial Aditya Athalye Change "Issed" to Issued" Editors Assigned to Editors. Status changed to Pending. Fix applied in latest uploaded Examples document. Status changed to Review Section 2.2.3 (WSS11 Anonymous With Certs) talks about a policy having Layout assertion as: <Layout> <Policy> <Strict/> </Policy> </Layout> The position of the <wsu:Timestamp> element is after the signature that signs it. examples spec editorial Aditya Athalye As per strict layout rules for WSS11, the <wsu:Timestamp> element should have occurred before the <ds:Signature> element covering it. The example should be rectified accordingly. Editors Assigned to Editors. Status changed to Pending. Fix applied in latest uploaded Examples document. Status changed to Review WS-SP Use cases doc states (Lines 968-969) "Line (M046) contains the Nonce element and Line (M047) contains a timestamp. These two elements should also be included in the PasswordText case for better security" The UsernameToken assertion in Security Policy supports only :<NoPassword>, and <HashPassowrd> assertion. UseCase: According to the use case document, Nonce, and Creation timestamp should be sent even for plain text passwords for better security which is a very valid requirement IMO. However, present security policy, and the schema(?) supports only HashPassword, which can indicate to the requestor, the provider's requirement for sending Password Digest, Nonce, and Created. If <HashPassword> is not present (assuming it is not <NoPassword>), it tells the requestor, that only Username, and clear text Password is mandatory. This no way indicates that the service may need a Nonce as well. So what it essentially means is that, service provider is actually offering a choice to the requestor: 1.) Send a plaintext password without Nonce/Created. (Less secure) - Acceptable to service: 2.) Send a plaintext password WITH Nonce/Created. (More Secure) - - Acceptable to service Obviously any requestor will take the less secure route to access to service. What should have happened is: Service provider unambiguously declaring its intention to check for Nonce/Created irrespective of PasswordType, and rejecting any messages which then do not conform to its policy. This leaves the requestor with only the more secure route to take. ws-sp spec design Aditya Athalye Previously discussed as issue 132 (http://docs.oasis-open.org/ws-sx/issues/Issues.xml#i132). Noted that the example document contains advice not coming from SP itself. Members need more time. Status changed to Active. Proposal to reat this as an SP enhancement request and defer to a future version of SP accepted. Status changed to Defer. Status changed back to active. This issue was erroneously brought out of the Deferred state in a previous meeting. Status changed (back) to Deferred. Examples 2.2.3 and 2.2.4 are identified as being based on WSS 1.1. However, both require the use of mechanisms (e.g. DerivedKeyToken) defined in WS-SecureConversation. The text refers to EncryptedKey as a WSS 1.1 feature, but EncryptedKey is defined by XML Enc and has been present in WSS since version 1.0. I am not sure if there is any dependency of these examples on WSS 1.1, but surely their use of WS-SecureConversation is a much more significant difference between them and the prior examples. examples spec editorial Hal Lockhart Rich Levinson Modify the titles of these examples to make it clear that they are examples of the use of WS-SecureConversation, not (just) WSS 1.1. See changes in document. Status changed to Active. Assigned to Rich Levinson. Status changed to review. Status changed to Closed. In lines 452-453 (M009-M010) <Nonce> and <Created> were inserted within the <Security> element. They should both be within the <UsernameToken> element. examples spec editorial Hal Lockhart Editors Status changed to Pending. Assigned to Editors. Status changed to review. Status changed to closed. "Line (P042) indicates that the Issed Tokens property is set to ‘true’" examples spec editorial Aditya Athalye Change Issed to Issued. Fix applied in latest uploaded Examples document. Status changed to Review Line 1932:The policy demands strict layout, whereas the message signature has occurred after the signature covering it. examples spec editorial Aditya Athalye I think in the example, the message signature should be placed before the Endorsing signature. Fix applied in latest uploaded Examples document. Status changed to Review Almost all example messages in the document are showing request messages which conform to policies. But there are no response messages examples. examples spec editorial Aditya Athalye Rich Levinson have examples of response messages conforming to policies especially for WSS11 scenarios, which have specific response requirements like <SignatureConfirmation> Status changed to Active The latest revision of the Examples doc has response messages added to example 3.2.4. Status changed to Review. Noted that review comments could come in two flavors: (a) comments on the response messages in example 3.2.4 and (b) comments to the effect that response messages should be supplied for additional examples. Closed on Oct. 3rd TC call Lines 1531-32: "Line (M035) indicates the BinarySecurityToken on Line (M024) is included in the signature as required by the ProtectTokens assertion of the AsymmetricBindingAssertion policy." Lines 1533-34: "Note that the initiator’s BinarySecurityToken is not included in the message signature as it was not required by policy." examples spec editorial Aditya Athalye remove lines 1533-34 Fix applied in latest uploaded Examples document. Status changed to Review The syntax of XPath Assertion should be changed from <sp:XPath> to <sp:XPath ...=""> This is related to the following four assertions: • SignedElements Assertion – Section 4.1.2 • EncryptedElements Assertion – Section 4.2.2 • ContentEncryptedElements Assertion – Section 4.2.3 • RequiredElements Assertion – Section 4.3.1 ws-sp spec design Symon Chang Symon Chang The syntax of XPath Assertion should be changed from <sp:XPath> to <sp:XPath ...=""> Proposal 3 accepted with comments from Ashok on Oct 17th TC call. The <sp:Trust13> assertion is not necessary for the policy in both Example 2.2.3 and 2.2.4. Looking into Policy Example 2.3.2.4 on page 75 of the Example Document, it has similar symmetric binding that uses <sp:X509Token> assertion with <sp:RequireDerivedKeys/>. This policy does not have <sp:Trust13> assertion. ws-sp spec design Symon Chang Symon Chang The <sp:Trust13> assertion in both Examples 2.2.3 and 2.2.4 should be removed for simplicity. Moved to Pending on Oct. 3rd TC call with proposal 2 (note to replace 2.3.2.5 with example from TC interop scenarios). Status changed to closed on Oct 17th TC call. The OASIS process requires all specs to now have a conformance section. ws-sc ws-sp ws-trust spec editorial Marc Goodner Editors Proposal one accepted with comments from Frederick, status changed to pending on Oct 16th TC call. I've been leafing through the specification and I wonder whether figure shown in section 4.3.7 is correct or not. You are using a RequestedTokenReference element to represent a proof-of-possesion token instead of a RequestedProofToken (as in examples in section 4.3.5 and 4.3.6)element with a SecurityTokenReference child element inside. Is the former correct? ws-trust spec editorial Carlos Gutiérrez Marc Goodner Proposal 1 accepted on Nov. 1 TC call. Closed on Nov 29th TC call The cd-01 version of WS-Trust is missing <wst:SecondaryParameters> element inside the RST message body skeleton on lines 394 - 398 even though the element itself is defined below on lines 419 - 426. ws-trust spec editorial Jan Alexander Jan Alexander Proposal accepted. closedon Nov 29th TC call. Current WS-Trust spec refers WS-Federation and WS-SC spec refers WS-MetadataExchange. These referred specifications have not been submitted to any standard body. I hope such references will be removed. ws-trust ws-sc spec design NISHIMURA Toshihiro NISHIMURA Toshihiro closed with no action on Nov. 15 TC call. In the first paragraph in Chapter 8 (Lines 1025-1031), references to SCT are divided into two categories: [a] references from within the <wsse:Security> element to a token also within the <wsse:Security> element [b] references from other parts of the SOAP envelope And then references within the <wsse:Security> element are divided into two subcategories : [a-1] reference (from within the <wsse:Security> element) to an SCT found within the message [a-2] references (from within the <wsse:Security> element) to a SCT not present in the message [a] can not diveded into [a-1] and [a-2], because [a] is "reference to a token within the <wsse:Security> element". I think [a] is intended to say just "references from within the <wsse:Security>" Later paragraphs in Chapter 8 describes three categories as follows: [A] reference from within the <wsse:Security> element or from an RST or RSTR (Lines 1040-1042) [B] reference from outside the <wsse:Security> element to SCT located in the <wsse:Security> element (Lines 1044-1047) [C] reference from within the <wsse:Security> element to SCT not present in the message (Lines 1049-1051) [A],[B] and [C] corresponds to [a-1], [b] and [a-2] except [A] mentions about RST and RSTR. I'd like to know the reason why reference from RST/RSTR is not categorized to [B]. I hope the reason will be described in the spec. ws-sc spec design NISHIMURA Toshihiro NISHIMURA Toshihiro Proposal 2 accepted on Nov. 15 TC call. Closed on Nov 29th TC call Chapter 8 (Lines 1040-1047) describes that using message independent referencing mechanism (using the <wsc:Identifier> ) is MUST/RECOMMENDED when SCT is referenced from RST, RSTR or from outside the <wsse:Security> element. But examples in Chapter 5 (Lines 622-659), Chapter 6 (Lines 704-734) and Chapter 8 (Lines 1054-1082) uses message-specific reference mechanism (using ID) in such case. ws-sc spec editorial NISHIMURA Toshihiro NISHIMURA Toshihiro Proposal accepted on Nov. 15 TC call. Closed on Nov 29th TC call WS-SecureConversation (http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversation-1.3-spec-cd-01.doc) line 365: change "an X.509 " to "an X.509 certificate" Line 602-603: "If a requestor desires to extend the duration of the token it uses a custom binding of the renewal mechanism defined in WS-Trust." "custom" is a word I prefer to avoid in standard specifications. I suggest rewording as follows (consistent with text used to describe the Cancel binding). "If a requestor desires to extend the duration of the token it uses this specialized binding of the renewal mechanism defined in WS-Trust" Line 701: change "even in the" to "even if the" line 776: change "possible" to "possibly" WS-Trust (http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-spec-cd-01.doc) line 392: change "wst:SecondaryParameter" to "wst:SecondaryParameters" line 1983: key-wrap-algorithm is in the middle of use-key lines 2008, 2014, 2020, 2030, 2046: remove periods from sentence fragments used to describe algorithm parameters to be consistent with the rest of the descriptions in this section. line 2034: change "symmetric key that" to "the symmetric key that" and change "message" to "messages" line 2040-2042: delete duplicate description of "EncryptWith" ws-trust ws-sc spec editorial Greg Carpenter Greg Carpenter Proposal 2 accepted on Nov. 15 TC call. Closed on Nov 29th TC call The RSTRC is mentioned in passing in the STS framework section 3.2 on the RSTR. It is again mentioned in the processing rules for the RSTC. The last mention is in the Issuance binding section 4.3 on the RSTR. From there on it appears in this section for the examples that show the RSTR. It continues to appear throughout the rest of the document where appropriate. However there is not a separate section with a description and exemplar for the RSTRC in Trust. Given that this element needs to be used so much in normal exchanges, providing a link to it in the TOC seems warranted. I do believe this is an editorial change as the element is already described in the text elsewhere and that there has been interop using it. trust spec editorial Marc Goodner Marc Goodner Proposal accepted on Nov. 15 TC call. Closed on Nov 29th TC call Section 6.7 has: LaxTimestampFirst LaxTimestampLast But Section 7.2 has: <sp:LaxTsFirst ...="" /> and <sp:LaxTsLast ...="" /> Proposed Resolution: Change section 6.7 to LaxTsFirst and LaxTsLast ws-sp spec editorial Hal Lockhart Hal Lockhart Closed with no action Jan 10, 2007 TC call Section 10 of WS-SP defines Trust10 assertion and says as follows: The Trust10 assertion allows you to specify which WS-Trust 1.0 options are supported. I assume we are not going to change the standardized version of WS-Trust to "WS-Trust 1.0". So, "WS-Trust 1.0" would be "WS-Trust 1.3". And it is better to provide sp:Trust13 instead of sp:Trust10 to avoid confusion. ws-sp spec editorial Toshiro Nishimura Editors Proposal to change to “1.3” to match spec version accepted on Jan 10, 2007 TC call. Status changed to Pending. Moved to Closed at Feb 28th TC call. In section 5.3.2, /sp:IssuedToken/sp:RequestSecurityTokenTemplate/@TrustVersion is described as follows: This optional attribute contains a URI identifying the version of WS-Trust referenced by the contents of this element. Does this mean the URI of WS-Trust document or the URI of WS-Trust namespace (or other URI?)? I hope this would be clarified ws-sp spec editorial Toshiro Nishimura Editors Proposal to use URI of WS-Trust document accepted on Jan 10, 2007 TC call. Status changed to Pending. Moved to Closed at Feb 28th TC call. Currently there is no way for a secure conversation STS to signal the client what WS-Trust bindings it supports. This issue was encountered during the recent SP interop testing where one of the participants STS didn’t except the SCT/Cancel RST messages but the client from another participant was sending SCT/Cancel RST messages to it. Currently it is necessary to exchange this information out of band in order to enable interoperability. Because the all WS-Trust bindings with the exception of Issue binding are optional it makes sense to add assertions to the security policy for SCT based tokens to indicate what bindings are supported for the issued SCT tokens. ws-sp spec design Jan Alexander Editors Proposal accepted on Jan 31, 2007 TC call. Status changed to Pending. Moved to Closed at Feb 28th TC call. On the Security Policy Examples document, there is an example of unencrypted plain text Username Token policy on 2.1.1.1, but there is no example for encrypted plain text Username Token policy. Sending unencrypted password text, as showed on 2.1.1.1, is not a secure way to handle the Username Token. The example should not be advertised as the only way to handle plain text password. We do have an encrypted plain text password policy on section 2.1.3 -- “(WSS 1.0) UsernameToken with Mutual X.509v3 Authentication, Sign, Encrypt”. However, this example requires signature. It is more complicated. Encrypted support token without signature is a very common use case. It is documented on the first WS-Security Interop Scenarios Document [WSS10-INTEROP-01 Scenario 1 – section 4.4.4] (http://www.oasis-open.org/committees/download.php/11374/wss-interop1-draft-06-merged-changes.pdf ). This is a real requirement for this use case scenario in the field, too. If a client does not have its own private key then the Username Token is the only way for authentication. If the server cannot accept digested password, then encrypted password is the only way to secure authentication. The client does not have key for signature, SignedEncryptedSupportingTokens assertion is not an alternative in this scenario. examples spec design Symon Chang Editors Proposal 2 accepted and assigned to the Examples Doc editors. Status changed to Pending. Moved to Closed at Feb 28th TC call. The current WS-SP spec has SupportingTokens, SignedSupportingTokens, and SignedEncryptedSupportingTokens assertions, but does not have EncryptedSupportingTokens assertion. Encrypted support token without signature is a common use case, when the plain text password is used on the Username Token for authentication, and the client does not have private key for signature. When the server can only accept plain text password, encrypt the password with server’s X509 certificate is a good security practice, but existing spec does not have a simply assertion in supporting token for this simple requirement. ws-sp spec design Symon Chang Editors Proposal 2 accepted and assigned to the SP Doc editors. Status changed to Pending. Moved to Closed at Feb 28th TC call. Currently the security binding [Signature Protection] property requires that all signature and signature confirmation elements MUST be encrypted when the property value is set to ‘true’. Given the fact that this property is only settable on security binding and security binding assertion can be associated with endpoint or operation scope only, it is not possible to express this requirement for individual messages or faults. Sometimes individual messages for a single operation may differ as to what message parts are encrypted in those messages. Generally, if there is nothing encrypted in the message, encrypting the signature does not add value from the security standpoint, it only degrades the performance. But given the current design, it is not possible to express signature protection requirement is such a way that would require signature element to be encrypted only for messages where there is at least one part encrypted. The proposal below changes the semantics of the [Signature Protection] assertion so that it is valid to have a signature element not encrypted if there is nothing else in the message that is encrypted if the [Signature Protection] property value is set to ‘true’. This allows capturing scenarios like the one above. ws-sp spec design Jan Alexander Editors Change the [Signature Protection] property description on lines 1305 – 1308 as follows: This boolean property specifies whether the signature must be encrypted. If the value is 'true', the primary signature MUST be encrypted and any signature confirmation elements MUST also be encrypted. The primary signature element is not required to be encrypted if the value is ‘true’ when there is nothing else in the message that is encrypted. If the value is 'false', the primary signature MUST NOT be encrypted and any signature confirmation elements MUST NOT be encrypted. The default value for this property is 'false'. Proposal accepted and assigned to the SP editors. Status changed to Pending. Moved to Closed at Feb 28th TC call. The current WS-SecurityPolicy specification does not provide any guidance or explicit support for expressing requirement for multiple supporting token of the same type. The main issue is that it is not really possible to differentiate between individual tokens if they share the same token type and thus matching the actual tokens with the token assertions in the receiver’s policy. The only exception is IssuedToken assertion, where it is possible to differentiate tokens based on the token issuer parameter. ws-sp spec design Jan Alexander Editors The proposal adds the optional issuer parameter to all token assertions defined in the specification. The existing sp:Issuer element as defined for IssuedToken, SpnegoContextToken and SecureConversationToken assertions is reused for this purpose. In addition to that it adds an optional claims parameter that allows the receiver to express required claims that have to be present in the token in order for the token to fulfill the token assertion requirements. The existing wst:Claims element from WS-Trust Issuance binding is reused for this purpose. The wst:Claims element allows the receiver to fine tune the token requirements in its policy. The proposal also clarifies the rules that govern the matching of the actual security tokens with the token assertions. Proposal accepted and assigned to the SP editors. Status changed to Pending. Moved to Closed at Feb 28th TC call. There is currently no assertion defined in security policy to indicate that an arbitrary key pair needs to be used in the message. There is class of scenarios where the sender needs to send an arbitrary public key to the recipient but such scenario cannot be currently captured by the security policy. The proposal is to add a new KeyValue token assertion to the specification. ws-sp spec design Jan Alexander Editors Moved to Closed at Feb 28th TC call. In SC the phrase “implied derived keys” is used, in SP “implicit derived keys” is used. We should be consistent across the specs. ws-sp spec editorial Marc Goodner Editors Change occurrences of "implicit derived keys" to "implied derived keys" to match SecureConversation Change the [Implicit Derived Keys] property to [Implied Derived Keys] Change all RequireImplicitDerivedKeys assertions to RequireImpliedDerivedKeys Proposal accepted and assigned to the SP editors. Status changed to Pending. Moved to Closed at Feb 28th TC call. Correct requirement to include policy element. ws-sp spec design Marc Goodner Editors Update description of instances of wsp:Policy as required instead of optional. /sp:*/wsp:Policy This required element identifies additional requirements for use of the sp:* assertion. Proposal accepted and assigned to the SP editors. Status changed to Pending. Moved to Closed at Feb 28th TC call. We updated the Trust assertion names to match the current version of the specification. We should do the same for the SC assertions ws-sp spec editorial Marc Goodner Editors Change all SC200502SecurityContextToken assertions to SC13SecurityContextToken Proposal accepted and assigned to the SP editors. Status changed to Pending. Moved to Closed at Feb 28th TC call. The current specification provides no mechanism to express the requirement to secure SOAP Messages with Attachments (SwA). ws-sp spec design Frederick Hirsch Editors Add to sp:SignedParts and sp:EncryptedParts sp:SignedParts/Attachment and sp:EncryptedParts/Attachment respectively. Proposal accepted and assigned to the SP Doc editors. Status changed to Pending. Moved to Closed at Feb 28th TC call. WS-Policy has progressed quickly at the W3C. WS-SecurityPolicy should be updated to allow the use of WS-Policy 1.5 in addition to the current reference to WS-Policy 1.2. ws-sp spec design Marc Goodner Editors 1. Add following text to WS-SecurityPolicy introduction: “The assertions defined within this specification have been designed to work independently of a specific version of WS-Policy. At the time of the publication of this specification the versions of WS-Policy known to correctly compose with this specification are WS-Policy 1.2 [current reference] and 1.5 [add reference to CR when available]. Within this specification the use of the namespace prefix wsp refers generically to the WS-Policy namespace, not a specific version.” Strike wsp from the namespace table. 2. Remove the hard dependency from the WS-SecurityPolicy XML Schema document to a specific version of WS-Policy: <xs:complexType name="NestedPolicyType"> <xs:sequence> <xs:element ref="wsp:Policy" /> <!-- remove this line --> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax"/> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="lax" /> </xs:complexType> The extensibility point that follows will allow the use of the nested policy. Proposal accepted and assigned to the SP editors. Status changed to Pending. Moved to Closed at Feb 28th TC call. WS-Trust defines the rules for interpreting the combinations of when a requestor specifies token scope and/or when the issuer returns token scope using the AppliesTo element. However, there is no way to give an STS control over when a requestor may/should specify the AppliesTo element in the RST request, and there are scenarios when such control would be useful. Of course, the STS always has the final say and can refuse a request lacking suitable AppliesTo, but without any a priori indication to a requestor that did not normally include AppliesTo info, the only option would be to fault and then retry. It would be useful to introduce a policy assertion that allows an STS to specify the requirement for scope information to be included in the form of AppliesTo in the RST. It would represent an intersectable behavior, and can very naturally fit under the top-level Trust assertion already defined in WS-SecurityPolicy that pertains to WS-Trust exchanges. ws-sp spec design Marc Goodner Editors Add <sp:RequiresAppliesTo/>? to the exemplar of Section 10.1 Trust13 Assertion with the following definition. /sp:Trust10/wsp:Policy/sp:RequireAppliesTo This optional element is a policy assertion indicates that the STS requires the requestor to specify the scope for the issued token using wsp:AppliesTo in the RST. Proposal accepted and assigned to the SP Doc editors. Status changed to Pending. Moved to Closed at Feb 28th TC call. On the 2/13 call there was some debate about whether or not the tokens identified in a binding assertion would be used for SignedParts, SignedElements, EncryptedParts, EncryptedElements assertions attached to a message. As there is no other place to specify the tokens to use for these assertions (as opposed to supporting tokens assertions that embed these assertions directly), it should be very clear that the binding assertion must be used. ws-sp spec design Tony Gullotta Editors Add to the text in the binding assertion section or the SignedParts, SignedElements, EncryptedParts, EncryptedElements assertions sections to make the connection more obvious. Proposal accepted and assigned to the SP Doc editors. Status changed to Pending. Moved to Closed at Feb 28th TC call. section 1 -- line 9: This document used to provide the value of the wsp prefix. Now it doesn't say how to get that value. In particular, it is defined in both WS-Policy and WS-PolicyAttachment, so we must be consistent. ws-sp spec editorial Christoper Leuder Add a sentence "Refer to the WS-Policy and WS-PolicyAttachment specifications for the value of the wsp namespace. The value of the namespace wsp is available from the referenced versions of the specifications. Close this issue with no action. Closed with no action on April 18, 2007 TC call section 1 -- line 9: This document refers to both WS-Policy and WS-PolicyAttachment, so we must be consistent. ws-sp spec design Christoper Leuder Clarify that consistent versions of WS-Policy and WS-PolicyAttachment specifications MUST be used. Close this issue with no action. Closed with no action on April 18, 2007 TC call section 1.4.1 -- line 129 The text appears to be truncated. The RFC reference is omitted. Proposal: Add the RFC 2119 reference. sections 5.2.1, 5.2.2 -- lines 727, 732: It references attribute, while it is talking about an element. Proposal: Change "attribute" to "element". section 5.2.4 -- line 752 : Strange text "to as multiple tokens as it sees fit." Proposal: Change text "to as many tokens as it sees fit." Or change to ", and apply to as many tokens as it sees fit." section 5.4.1 -- line 832 : Slash "/" is missing. Proposal: Add "/" before "sp:Issuer". section 5.4.7 -- line 1255: wsp:Policy is now required, and its contents are optional. But the "?" is in the wrong place. Proposal: Put the "?" on line 1257 rather than on line 1255. sections 8.2, 8.3, 8.4 -- lines 2297, 2352, 2409: Spurious "|" symbol. Proposal: Delete the "|" symbol or add ellipses after it "...". section 10.1 -- line 2773 : Confusing text. Proposal: Clarify the text "element is a policy assertion indicates", maybe by adding "that" before "indicates". ws-sp spec editorial Christoper Leuder See Description Proposed editorial changes adopted and assigned to editors on April 18, 2007 TC call. Status changed to Pending. Updates are in the approved SP Committee Spec. Status changed to Closed. Multiple sections, lines 456, 505,536, 586, 613 Difficult to parse. Proposal: Replace "binding specific" with "binding-specific" multiple sections, lines 730, 734: intended use outside the scope of this specification is immaterial Proposal: replace "is intended to be used" with "may be used" section 5.2.2 -- line 733: verb usage Proposal: Replace "points" with "pointing" section 5.4.11 -- line 1552 : plural agreement Proposal: Replace "by another specifications" with "in other specifications" section 8.6 -- line 2460 : only modifies when, not used Proposal: Replace "only used when" with "used only when" ws-sp spec editorial Jackson Wynn See Description Do not accept the the first two proposed changes. Accept the remainder. First two proposed changes in NOT adopted. Remaining three proposed changes adopted and assigned to editors. Status changed to Pending. Updates are in the approved SP Committee Spec. Status changed to Closed. Lines 495,576: Line 174 references SOAP 1.1 and 177 referencces SOAP 1.2, but line 197 SWA and 278 SWA-Profile are specific to SOAP 1.1 only. The sp:Attachments is therefore specific to just SOAP 1.1. It should be generalized to be inclusive of SOAP 1.2 by referencing the SOAP 1.2 attachment mechanism as well: Message Transmission Optimization Mechanism (MTOM).. ws-sp spec design Christoper Leuder Add reference to Message Transmission Optimization Mechanism (MTOM) in addition to SWA. Close this issue with no action. Closed with no action on April 18, 2007 TC call section 5.4.5: The SpnegoContextToken includes STS capabilities assertions, e.g., MustNotSendCancel, MustNotSendRenew, etc., which are properties of the STS not the token. This tight coupling between the token and the STS server requires the list of assertions be adjusted. section 5.4.7: The SecureConversationTokens includes STS capabilities assertions which are properties of the STS not the token. This tight coupling between the token and the STS server requires the list of assertions be adjusted ws-sp spec design Jackson Wynn, Fold these STS capability assertions into WS-Trust assertion Close this issue with no action. Closed with no action on April 18, 2007 TC call section 5.4.5 -- lines 1152, 1156, 1160: Descriptions are inconsistent with the element tag names section 5.4.7 -- lines 1297, 1301, 1305: Same comment as for lines 1152, 1156, and 1160. ws-sp spec design Christoper Leuder Change "/sp:MustNotSendCancel" to "/sp:CancelNotSupported", or change the description to state explicitly that the Cancel must not be sent. Change "/sp:MustNotSendAmend" to "/sp:AmendNotSupported", or change the description to state explicitly that the Amend must not be sent. Change "/sp:MustNotSendRenew" to "/sp:RenewNotSupported", or change the description to state explicitly that the Renew must not be sent. Interop has been conducted using the existing names. The semantics described in the associated text are correct. Closed with no action on April 18, 2007 TC call ws-sp spec editorial Christoper Leuder section 5.2.2 -- line 740: Change "cannot" to 'MUST NOT" section 5.2.3 -- line 746: Capitalize "MUST"? Also, please review other places where "may" and "must" appear for consistency, e.g., line 749. section 6.4 -- line 1692: Change "is not required to" to "SHOULD NOT" or to "OPTIONAL"? Not clear which choice is intended. section 8.1 -- line 2230: Change "can" to "MAY". section 8.6 -- line 2455: Change "can" to "MAY". Close this issue with no action. Closed with no action on April 18, 2007 TC call section 5.2.3 -- lines 743,744: The statement that this specification will not further define this element should not be followed by more information about it ws-sp spec editorial Jackson Wynn Move this statement to the end section 5.2.3 Close this issue with no action. Closed with no action on April 18, 2007 TC call lines 840, 908, 989, 1076, 1137,1199, 1275, 1397, 1468, 1534: “This optional element identifies the required claims that a security token must contain in order to satisfy the token assertion requirements” ws-sp spec editorial Jackson Wynn lines 840, 908, 989, 1076, 1137,1199, 1275, 1397, 1468, 1534: Remove "the" or replace with "all" Close this issue with no action. Closed with no action on April 18, 2007 TC call section 10.1, line 2772-2773: The value of the "sp:RequireAppliesTo" element is ambiguous. Is it an empty element, or does it contain a reference to an entity that the policy applies to? ws-sp spec design Christoper Leuder Clarify what is the value of the "sp:RequireAppliesTo" element. Close this issue with no action. Closed with no action on April 18, 2007 TC call The URI value for IncludeToken is different between the XML schema xsd file and the current WS-SecurityPolicy spec. The current WS-SP schema (ws-securitypolicy-1.2.xsd) has the following values for IncludeToken: <xs:simpleType name="IncludeTokenType"> <xs:restriction base="xs:anyURI"> <xs:enumeration value="http://docs.oasis-open.org/ws-sx/ws-trust/200702/ws-securitypolicy/IncludeToken/Never";/> <xs:enumeration value="http://docs.oasis-open.org/ws-sx/ws-trust/200702/ws-securitypolicy/IncludeToken/Once";/> <xs:enumeration value="http://docs.oasis-open.org/ws-sx/ws-trust/200702/ws-securitypolicy/IncludeToken/AlwaysToRecipient";/> <xs:enumeration value="http://docs.oasis-open.org/ws-sx/ws-trust/200702/ws-securitypolicy/IncludeToken/AlwaysToInitiator";/> <xs:enumeration value="http://docs.oasis-open.org/ws-sx/ws-trust/200702/ws-securitypolicy/IncludeToken/Always";/> </xs:restriction> </xs:simpleType> The WS-SecurityPolicy spc (ws-securitypolicy-1.2-spec-cs.doc) section 5.1.1 has the URI of: http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToInitiator http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Always ws-sp spec editorial Martin Raepple Editors This is a spec/schema mismatch. The spec is clear and correct. The schema typo will be corrected using the errata process. Issue number will be updated to use the "ER" prefix (ER001) to flag this as an issue to be addressed via errata. Assigned to editors. Status changed to Pending. Moved to review on Oct. 3rd TC call. Status changed to closed on Oct 17th TC call. Lines 2097ff: "The specified token populates the [Recipient Signature Token] property and is used for the message signature from Recipient to recipient." should be changed to Lines 2097ff: "The specified token populates the [Recipient Signature Token] property and is used for the message signature from recipient to the initiator. Lines 2103ff: "The specified token populates the [Recipient Encryption Token] property and is used for the message encryption from recipient to Recipient." should be changed to Lines 2103ff: "The specified token populates the [Recipient Encryption Token] property and is used for the message encryption from initiator to recipient." ws-sp spec editorial Martin Raepple Editors Assigned to editors. Status changed to Pending. Moved to review on Oct. 3rd TC call. Status changed to closed on Oct 17th TC call. Section 7 (Deriving Keys) in WS-SecureConversation refers to policy assertions for label and length of derived keys that do not exist in WS-SP 1.2: Lines 780ff: "Labels are processed as UTF-8 encoded octets. If either isn't specified in the policy, then a default value of "WS-SecureConversation" (represented as UTF-8 octets) is used." Lines 892ff: "If additional information is not specified (such as explicit elements or policy), then the following defaults apply: The offset is 0 / The length is 32 bytes (256 bits)" ws-sp ws-sc spec editorial Martin Raepple Editors Option 1: Remove references to policy in the text as follows: Lines 780ff: "Labels are processed as UTF-8 encoded octets. If additional information is not specified as explicit elements, then a default value of "WS-SecureConversation" (represented as UTF-8 octets) is used." Lines 892ff: "If additional information is not specified as explicit elements, then the following defaults apply:" Option 2: Explicitly refer to custom / non-standard policy assertions Option 3: Add policy assertions for label and length (e.g. as new attributes/elements to the Derived Keys Property) to SP Assigned to editors. Status changed to Pending. Moved to review on Oct. 3rd TC call. Status changed to closed on Oct 17th TC call. The example given in section 5.4.7, SecureConversationToken Assertion, lines 1271ff, contains a wrong policy assertion for the Security Context Token: Line 1281: sp:SC10SecurityContextToken should be changed to Line 1281: sp:SC13SecurityContextToken ws-sp spec editorial Martin Raepple Editors See Description Assigned to editors. Status changed to Pending. Moved to review on Oct. 3rd TC call. Status changed to closed on Oct 17th TC call. Lines 526-529 "Such encryption will encrypt such elements using WSS 1.1 Encrypted Headers. As such, if WSS 1.1 Encrypted Headers are not supported by a service, then this element cannot be used to specify headers that require encryption using message level security." Does this mean, that if as a service provider, I cannot understand what a EncryptedHeader means, then clients requesting this service cannot encrypt any of the request soap headers using message level security? ws-sp spec editorial Aditya Athalye Prateek Mishra I agree that EncryptedHeader could help protect sensitive attributes on the soap header, but I doubt if EncryptedHeader has gained sufficient popularity amongst implementors. I believe till the time, it is universally adopted, and implemented by all, the above restriction of not being able to use message level security for header confidentiality should not be in place. This IMO can hurt interoperability between vendors who support this, and those who don't.Furthermore, till such time, EncryptedData can be used by service providers and requestors. TC members had trouble understanding the issue and what is being proposed. The issue originator was not present on the call. Prateek will seek clarification from Aditya Closed with no action. Does this mean, that if the [Timestamp] property is set to false, or <includeTimestamp> is absent, and yet if a request/response <wsse:Security> header contains a <wsu:Timestamp>, then this should be treated as violation entailing a rejection of such a request/response? My question is: Is this intended behaviour? Is there a practical use case for this? I guess most implementors follow the following algorithm/truth table: Policy Actual Result True True Accept True False Reject False False Accept False True Accept The highlighted values in the truth table are something we noticed implementors (in WS-Policy interop event) doing, which means that if [Timestamp] is set to false, ignore the <wsu:Timestamp> element="" if found inside <wsse:Security> header, and thus accept the message. Should the spec be updated accordingly, or should vendors change their implementation? ws-sp spec editorial Aditya Athalye Marc Goodner Two proposals, a and b, described in message outlining positions. Lines 592-593 /sp:ContentEncryptedElements/@XPathVersion This optional attribute contains a URI which indicates the version of XPath to use. ws-sp spec editorial Aditya Athalye Editors As with all other assertions that use XPath, this assertion element should also explicitly state the following: /sp:ContentEncryptedElements/@XPathVersion This optional attribute contains a URI which indicates the version of XPath to use. If no attribute is provided, then XPath 1.0 is assumed. Assigned to editors. Status changed to Pending. Moved to review on Oct. 3rd TC call. Status changed to closed on Oct 17th TC call. The WS-SP spec attaches a @IncludeToken for the various security tokens that are defined. The Token Inclusion values are also enumerated in Section 5.1.1. However, the spec does not clearly indicate the applicability of various Inclusion Values for each token. What I mean is: Not all TokenInclusion Values defined will be applicable/pertinent to each security token. UseCase: 1.) For a UsernameToken, using TokenInclusion values of "Never", or "AlwaysToInitiator" may not be relevant. A policy cannot use something like "RequireKeyIdentifierReference" for referencing UsernameTokens, so probably a UsernameToken will always be included, and probably always sent from Initiator to Recipient. 2.) A SAMLToken may never need to use an Inclusion value of "AlwaysToInitiator". 3.) An X509Token can use any of these values depending on the scenario. ws-sp spec editorial Aditya Athalye Aditya Athalye I propose that the spec also throw some light on this aspect in the description for @IncludeToken for each such token, so that implementors/users get a clear idea of this. Following quoted text could be added to the UNToken: This optional attribute identifies the token inclusion value for this token assertion. "It is RECOMMENDED however that this security token uses the "Always", "AlwaysToRecipient", "Once" inclusion values". Similar text can be added for the remaining tokens wherever applicable.The schema can still use the "IncludeTokenType", but the documentation IMO could be a little clearer. Closed with no action. As we know WS Policy does not use Policy Assertion parameters when intersecting Policy Assertions. IMO this would impact WS Security Policy to certain extent. eg: Alternative A ------------------------------- <sp:AsymmetricBinding > <wsp:Policy> <sp:InitiatorToken > <sp:X509Token sp:IncludeToken = ".....Never"> <wsp:Policy> <sp:RequireDerivedKeys ...="" /> <sp:RequireKeyIdentifierReference ...="" /> </wsp:Policy> </sp:X509Token> </sp:InitiatorToken > <sp:RecipientToken > <sp:X509Token sp:IncludeToken = ".......Never"> <wsp:Policy> <sp:RequireDerivedKeys ...="" /> <sp:RequireKeyIdentifierReference ...="" /> </wsp:Policy> </sp:X509Token> </sp:RecipientToken > </wsp:Policy> </sp:AsymmetricBinding > Alternative B ------------------------------- <sp:AsymmetricBinding > <wsp:Policy> <sp:InitiatorToken > <sp:X509Token sp:IncludeToken = "......Always"> <wsp:Policy> <sp:RequireDerivedKeys ...="" /> <sp:RequireKeyIdentifierReference ...="" /> </wsp:Policy> </sp:X509Token> </sp:InitiatorToken > <sp:RecipientToken > <sp:X509Token sp:IncludeToken = "......Always"> <wsp:Policy> <sp:RequireDerivedKeys ...="" /> <sp:RequireKeyIdentifierReference ...="" /> </wsp:Policy> </sp:X509Token> </sp:RecipientToken > </wsp:Policy> </sp:AsymmetricBinding > When intersected with the default algorithm of the policy framework the resulting policy would contain mutually contradictory X509Token parameters. On one hand, the resulting policy would require never to include X509Tokens while at the same time always requiring to include X509Tokens. The intersection result would effectively yield an invalid policy. ws-sp spec design K Venugopal Editors Formerly Issue i134 renumbered as Errata. Proposal accepted. Assigned to editors. Status changed to Pending. Moved to review on Oct. 3rd TC call. Status changed to closed on Oct 17th TC call. 6.7 Security Header Layout: LaxTimestampFirst As Lax except that the first item in the security header MUST be a wsse:Timestamp. LaxTimestampLast As Lax except that the last item in the security header MUST be a wsse:Timestamp. ws-sp spec editorial Aditya Athalye Editors Change both these occurrences to wsu:Timestamp Status changed to Pending Moved to review on Oct. 3rd TC call. Status changed to closed on Oct 17th TC call. See Proposal ws-sp spec editorial Aditya Athalye Editors Status changed to Pending Moved to review on Oct. 3rd TC call. Status changed to closed on Oct 17th TC call. Per action item AI-2007-04-18-03. The spec should be reviewed for consistent use of normative language per RFC 2119. ws-trust spec editorial Greg Carpenter Editors Per action item AI-2007-04-18-03. The spec should be reviewed for consistent use of normative language per RFC 2119. ws-sc spec editorial Greg Carpenter Editors Per action item AI-2007-04-18-03. The spec should be reviewed for consistent use of normative language per RFC 2119. ws-sp spec editorial Greg Carpenter 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 Final tracked by this AI. Issues being raised to continue progress. 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. Done Done Done Done Done Done Done Done Done Done No action required Ongoing. ETA is late July/early August Done Done Done Done Done Done Prateek has additional information from Aditya that he will consolidate and send to the TC list. Done. Recommendation is to close ER005 with no action. Done Done