http://docs.oasis-open.org/ws-sx/issues/
WS-SX TC Issues List
Date: 2008/09/16
Revision: 99
spec
schema
soap
wsdl
policy
all
interop
New
Active
Pending
Review
Deferred
Closed
Dropped
Revocation versus cancelation of security tokens
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.
Signed parts clarifications
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
Use of term "binding" in specs
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
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.
OASIS formatted specs
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.
Adopt errata of SP into initial drafts
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
Put schema and wsdl in well identified place
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
Need well formed XML examples
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
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.
Proof of possesion for security intermediaries
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.
WS-SX Charter XPath reqts and WS-SecurityPolicy use of XPath (5.1, 5.2) appear in conflict
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.
Examples should have <ds:SignatureValue> subelement, not <ds:Signature>
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.
Add the OASIS boilerplate to the XSD and WSDL files
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.
Is the key agreement algorithm proposed in WS-Trust sound?
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.
Support error handling in RequestSecurityToken extension
mechanism
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.
sp:SignedParts mechanism
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.
sp:RequiredElements mechanism
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.
absolute XPath expressions
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.
supported XPath expressions
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.
Describe minimum acceptable lengths for P_SHA1 inputs
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
Correct section numbers in SP
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.
XML tags of properties according to the properties
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.
Properties for Algorithm Suite missing or wrong
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.
[Protection Order] Property using same source for keys
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
Chap. 6.5 [Token protection] conflicts with chapter 8.3 and 8.4
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.
Chapter 6.7 [Security Header Layout]
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.
When to include a token?
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.
Multiple supporting tokens of the same type?
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
Which token to use to encrypt/sign in case of multiple tokens defined in a supporting token assertion?
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.
Need a mechanism to identify token assertions
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.
Clarification for UsernameToken assertion
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
WS-SP should permit Policy to specify the use of keys derived from passwords
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.
Identify security header components that are signed and/or encrypted
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
Editorial comments on WS-Trust
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.
Requester cannot fault upon response
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.
Clarify term pre-authentication
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/IssuedTokens schema
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.
Clarify that ComputedKey optional
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.
Define URI for no-correlation anonymous context case
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.
What values can be carried in a /wst:RequestSecurityToken/wst:Claims
element?
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
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 HTTP Binding
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.
Missing enumeration for validate request type in the RequestTypeEnumdefinition
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
What is an authorization token?
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.
Duplicate Id attribute values in Security Context example
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.
Include BinarySecurityToken as an additional token assertion in WS-SP
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.
Does IssuedTokenOverTransport require client-side digital signature?
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
Binding Assertions should support Operation subjects
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.
Clarify that [Algorithm Suite] applies to message level
cryptography and NOT transport-level cryptography
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.
Clarify scope of Protection assertions
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.
sp:RequireDerivedKeys is underspecified
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.
Add single request for multiple tokens
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.
Message parts to be protected using BootstrapPolicy
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.
Clarification on Signature Protection property and various SupportingTokens
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.
Clarification on RequireDerivedKeys and X509Token under AsymmetricBinding
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
Add new Bearer Token KeyType
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.
Final protocol message should always be an RSTRC
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
Validate binding should have a ValidateTarget
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
Final protocol message should have a distinct action
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
New binding for STS starting the token cancellation process
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.
Add wsc:Length attribute to the Implied derived key
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.
Where is UML generated schema more restrictive than the SP schema?
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
Tony Nadalin
CLosed with no action.
Error in the WS-SecurityPolicy Schema
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?
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 receiving cancel messages
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
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.
Resolving Policies if more than one SecureConversationToken is
present
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
Security considerations for relying parties
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
Default assertions and policy intersections
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.
Clarify relationship between extensibility model and policy intersection
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
Guidance on Policy Application
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.
Missing KeyWrapAlgorithm requirement in section 9.2
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.
Key and Encryption Requirements Clarification
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
Add <EncryptSupportingToken> element to Sections 7.4 and7.5
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.
HTTP Auth Subassertions
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.
How to reference a specific SC when initiating a session?
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
Use of Section 8 from WS-SC forces applications to be WSS schema aware
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.
Specify Reference Types for References to SCT
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
Is Bootstrap policy a PolicyAssertion
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.
Handling EncryptParts specified under SupportingTokens
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.
Provide policy statements and associated URIs that can be
referenced from wsp:PolicyReference statements
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
Remove duplicate RFC2119 reference
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.
Remove shading from figures, possibly enlarge
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.
Assertions with nested policy do not indicate it
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.
Replace ID with Id for Id attribute
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.
No policy support for content encryption?
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.
Matching assertion with empty nested Policy with assertion with no nested policy
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.
No XPath default
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.
Minor editorial comments on security policy
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.
Description of Strict Formatting seems wrong for EncryptedKey
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
security policy help for example C.3.2
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.
Proposed SP change related to issue 52
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
Need a holder for token assertions within the SupportingTokens assertions
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.
We need a definition for "domain" in WS-SecurityPolicy
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.
Amend text for nested assertions in WS-SP
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.
Ensure Appendix A is complete
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.
No support for message level encryption of headers for WSS 1.0?
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.
Inconsistencies related to SignedParts/* assertion
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.
The <IssuedTokens> Element is not used by WS-SC
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
Lack of Rationale for choices of Authentication for WS-SC
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
Need additional SamlToken Assertion Elements for Holder-of-Key and Sender-Vouches
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
Add section numbers and line numbers to interop document
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.
Interop document - Clarify that RSTR is returned in RSTRC
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.
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.
SC label concatenation rules unclear
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.
Why does a <IssuedTokens> element contain an RSTR instead of an RSTRC?
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
Apparent typo in WS-Sp Schema comments
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.
Potential attack when using RST parameters from a target site - WS-Trust part
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
Potential attack when using RST parameters from a target site - WS-SecurityPolicy part
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
QName support for specifying elements that need to be present in the message
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.
Clarification on IssuedToken and SecureConversationToken assertions
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.
Clarification: BootstrapPolicy to indicate the security context token created by one of the communicating parties
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 in SC needs to be updated for RSTRC
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
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.
Universal Encryption of UsernameToken (as specified by Appendix D, d.4, 3.) seems wrong
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
Is Appendix D Normative?
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
Element or Content Encryption on SignedEncryptedSupportingTokens Assertion
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.
Wrong ProtectionToken Policy in chapter 1.1
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
non-normative information in normative part
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
minor editorial comments on Trust and WS-SecureConversation
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
Reference to WS-Policy in WS-Trust
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.
Use cases should include example messages and descriptions on how header content corresponds to policy.
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
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
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
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
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
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
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
Example 2.2.3 and 2.2.4, Trust10 should be changed to Trust13
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
Example 2.3.2.1
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
Absence of a Confirmation to Nonce
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
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
Need provision in the spec/schema for attachment content signature
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.
Closed with no action on Oct 31st TC call.
Incorrect URI for password digest in the example
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
Support for more stringent security implementation in WS-SP as per requirements in WS-SP Usecases document
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.
Editorial correction in WS-SP usecases draft Example 2.2.3
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
Editors
"...an X.509 token MUST NOT be included with any message sent between Initiator and Recipient" ?
Assigned to Editors. Status changed to Pending.
Fix applied in latest uploaded Examples document. Status changed to Review
Incorrect spelling of Issued Tokens WS-SP usecases draft Example 2.2.3
Lines 1638: Line (P042) indicates that the Issed Tokens property is set to ‘true’
examples
spec
editorial
Aditya Athalye
Editors
Change "Issed" to Issued"
Assigned to Editors. Status changed to Pending.
Fix applied in latest uploaded Examples document. Status changed to Review
Incorrect order of <Timestamp> element for Strict Layout
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
Editors
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.
Assigned to Editors. Status changed to Pending.
Fix applied in latest uploaded Examples document. Status changed to Review
Support for nonce and created nested assertion in usernametoken
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.
Proposal 4 accepted, assigned to Editors. Status changed to Pending.
Status changed to review on Feb 6 TC call.
Status changed to closed on Feb 20 TC call.
Examples 2.2.3 and 2.2.4 are miss-labeled
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.
Typo in Example 2.1.1.3 Message
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.
Typo error in Section 2.2.4
"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
Incorrect Order of Message signature in WSS11 Mutual Auth Scenario
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
Example to illustrate a response message
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
Contradictory statements made in WSS10 Mutual Auth Scenario
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
Syntax of XPath for Signed, Encrypted and Required Elements
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.
Status changed to review on Feb 6 TC call.
Status changed to closed on Feb 20 TC call.
Trust13 assertion should be removed from the policy Example 2.2.3 and 2.2.4
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.
Add conformance statements to new versions of Trust/SC/SP
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.
Status changed to review on Feb 6 TC call.
Status changed to closed on Feb 20 TC call.
Update SP per Policy 1.5 guidelines
I’ve reviewed the Policy 1.5 guidelines doc and in general didn’t find much, see attached. The one thing we didn’t do was handle in prose what to do for wsp:Ignorable according to guidelines 9 (describe in prose) and 10 (describe in XML). In many instances we’ve handled the XML job already. The instances where it isn’t handled is where there is attribute extensibility, say for wsp:Optional, which would incorrectly permit the use of wsp:Ignorable. So we can pull SP into shape from the guidelines perspective by adding prose that it isn’t allowed. For RM that would be a specific statement for the only assertion that allows attribute extensibility, for SP it would be a global statement up front. My suggested text follows.
ws-sp
spec
editorial
Marc Goodner
Editors
Proposal one accepted, status changed to pending on Oct 31st TC call.
Status changed to review on Feb 6 TC call.
Status changed to closed on Feb 20 TC call.
Update policy references to 1.5 for SC, Trust and SP
We need to update our references for WS-Policy to the W3C Recommendation version 1.5.
See message for complete description/proposl.
ws-sp
ws-sc
ws-trust
spec
design
Marc Goodner
Marc Goodner
Proposal one accepted, status changed to pending on Nov 28th TC call.
Status changed to review on Feb 6 TC call.
Status changed to closed on Feb 20 TC call.
Generalized Interactive Challenge for WS-Trust
See message for complete description/proposl.
ws-trust
spec
design
Marc Goodner
Marc Goodner
Proposal 1 accepted, assigned to Editors. Status changed to Pending. Note new issues related to accepted proposal: i155 to i159.
Status changed to review on Feb 6 TC call.
Status changed to closed on Feb 20 TC call.
Examples doc issues
See message for complete description/proposl.
examples
spec
design
Tony Nadalin
Status changed to Review on Apr 30 TC call
Status changed to Closed on May 14 TC call
Generalized Interactive Challenge for WS-Trust - Concern 1
See point 1 in message for complete description.
ws-trust
spec
design
Hal Lockhart
Closed with no action on Feb 6 TC call.
Generalized Interactive Challenge for WS-Trust - Concern 2
See point 2 in message for complete description.
ws-trust
spec
design
Hal Lockhart
Proposal 2 accepted on Mar 5 TC call (change SHOULD to MAY), status changed to pending
Status chaged to review on Mar 19 TC call
Status chaged to closed on Apr 2 TC call
Generalized Interactive Challenge for WS-Trust - Concern 3
See point 3 in message for complete description.
ws-trust
spec
design
Hal Lockhart
Proposal 1 accepted on Mar 5 TC call, status changed to pending
Status chaged to review on Mar 19 TC call
Status chaged to closed on Apr 2 TC call
Generalized Interactive Challenge for WS-Trust - Concern 4
See point 4 in message for complete description.
ws-trust
spec
design
Hal Lockhart
Proposal 2 accepted on Mar 5 TC call, status changed to pending
Status chaged to review on Mar 19 TC call
Status chaged to closed on Apr 2 TC call
Generalized Interactive Challenge for WS-Trust - Concern 5
See point 5 in message for complete description.
ws-trust
spec
design
Hal Lockhart
Proposal 1 accepted on Mar 5 TC call, status changed to pending
Status chaged to review on Mar 19 TC call
Status chaged to closed on Apr 2 TC call
Unclear behavior for RequireSignatureConfirmation Assertion where there is no Signature
See message for complete description.
ws-sp
spec
design
Hyen V Chung
Editors
Proposal 1 accepted, status changed to pending on Apr 2 TC call
Status changed to Review on Apr 30 TC call
Status changed to Closed on May 14 TC call
Add sp:RequireAsync into sp:Trust13 assertion
See message for complete description.
ws-sp
spec
design
Symon Chang
Closed with no action. Status changed to closed on Feb 20 TC call.
No way to specify the policies for renew and cancel
See message for complete description.
ws-sp
spec
design
Corinna Witt
Status changed to Review on May 14 TC call
Status changed to Closed on May 28 TC call
Document how to support out of band encryption key known to both parties
See message for complete description.
New thread with improved description.
examples
spec
design
Ruchith Fernando
Updated from original proposal
Status changed to Review on Apr 30 TC call
Status changed to Closed on May 14 TC call
Provide means to specify which signing transform to use for attachments
See message for complete description.
ws-sp
spec
design
Frederick Hirsch
Editors
Proposal 1 accepted on Feb 20 TC call
Status changed to Review on the Apr 16 call.
Status changed to Closed on May 28 TC call
SP errata
See message for complete description.
ws-sp
spec
editorial
Marc Goodner
editors
Proposal 1 accepted on Mar 5 TC call, status changed to pending
Status chaged to review on Mar 19 TC call
Status chaged to closed on Apr 2 TC call
Error on transport binding example?
See message for complete description.
ws-sp
spec
editorial
Public list
Marc Goodner
Proposal 1 accepted on Mar 19 TC call, status changed to pending
Status changed to Review on the Apr 16 call.
Status changed to Closed on May 28 TC call
Missing element for requesting a security token to actas a different identity
See message for complete description.
ws-sp
spec
editorial
Marc Goodner
Editors
Proposal 1 accepted on Mar 19 TC call, status changed to pending
Status changed to Review on the Apr 16 call.
Status changed to Closed on May 14 TC call
Policy to require persisted trace log encryption?
See message for complete description.
ws-sp
spec
editorial
Public list
Hal Lockhart
Response sent to public comment list on Apr 2
Sample wsdl in conflict w WS-I BSP in WS-Trust1.3, 1.4
See message for complete description.
ws-trust
spec
editorial
Public list
Rich Levinson
Status changed to pending on July 09 TC call
Status changed to closed on July 23 TC call
Update XML Signature references to refer to XML Signature, Second Edition, update c14n reference in ws-trust
See message for complete description.
ws-trust
spec
editorial
Frederick Hirsch
Frederick Hirsch
Status changed to Active on Sep 3 TC call
Incorrect URI provided for Canonical XML 1.0 when defining C14n abbreviation
See message for complete description.
ws-trust
spec
editorial
Frederick Hirsch
Frederick Hirsch
Question on WS-Trust sections 4.3.5 to 4.3.7
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
RST message body template is missing <wst:SecondaryParameters>
element
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.
References to non-standard specifications
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.
Categorization of SCT references is unclear
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
Examples should use recommended mechanism
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
minor editorial comments on WS-Trust and WS-SecureConversation
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
RSTRC is not described in exemplar in Trust
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
Element Names Inconsistent in Layout Policy
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
WS-Trust "1.0" in WS-SecurityPolicy
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.
Value of @TrustVersion is not clear
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.
Missing assertions to indicate supported bindings for the secure conversation STS
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.
Need policy example for encrypted username token
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.
Need EncryptedSupportingTokens assertion
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.
Signature protection semantics clarification
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.
Missing issuer and required claims inside token assertions
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.
Missing assertion to indicate arbitrary RSA public key to be used as a security token
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.
Use derived keys language consistent with WS-SecureConversation
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
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.
Update SC Assertion Names to match current spec
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.
No means to express need to secure SOAP Messages with
Attachments (SwA)
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.
Allow W3C version of WS-Policy to be used
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.
Assertion to allow STS to require requestor to specify scope of issued token
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.
It should be more clear as to which token is used by a protection assertion
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.
SP document doesn't say how to get a value for the wsp: prefix
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
Clarify that consistent versions of WS-Policy and WS-PolicyAttachment specifications MUST be used.
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
Editorial comments on WS-SecurityPolicy Public Review document
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.
Editorial comments on WS-SecurityPolicy Public Review document
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.
Add reference to Message Transmission Optimization Mechanism (MTOM) in addition to SWA.
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
Move capability assertions (e.g., MustNotSendCancel, MustNotSendRenew, etc.) which are properties of the STS not the token, into WS-Trust assertion
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
Descriptions are inconsistent with the element tag names (/sp:MustNotSendCancel, /sp:MustNotSendAmend, "/sp:MustNotSendRenew").
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
Inconsistencies with RFC 2119
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
statement that this specification will not further define the wst:claims element should not be followed by more information about it
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
plural agreement
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
Ambiguous value for "sp:RequireAppliesTo" element
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
Apply the changes described in the resolution to issue i169 to the Trust 1.3 errata
See message for complete description.
ws-trust
spec
design
Editors
Greg Carpenter
Apply the example WSDL changes described in the resolution to i169 to the Trust v1.3 errata
Moved to Pending on July 23, 2008 TC call
Moved to Closed on Aug 20, 2008 TC call
Questions on Versioning Problems of WS-SecureConversation
See Message for details
ws-sc
spec
design
Public Comment
Inconsistent IncludeToken URI between spec and schema xsd file
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.
Editorial comments on SP
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.
Clarification of policy usage for derived keys in SC
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.
Wrong Security Context Token assertion in example
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.
Restriction on Encryption of Headers
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.
The specification states that if [Timestamp] is false, thenwsu:Timestamp
should not be present inside <wsse:Security> header.
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.
Add statement to global section consistent with text from section 2.3 that a service may choose to accept messages that do not conform to its policy.
Proposal two accepted, status changed to pending on Oct 16th TC call.
Moved to review on Dec. 12th TC call.
Moved to closed on Jan. 9th TC call.
Minor editorial addition to <ContentEncryptedElements> Assertion
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.
Applicability of TokenInclusion Values for various security tokens
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.
Policy Assertion Parameters and alternatives
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.
Typo in the Security Header Layout section
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.
Modification request for issue PR014
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.
Review normative RFC 2119 language in WS-Trust
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
Proposal 1 accepted, status changed to pending on Jan 9 TC call.
Status changed to review on Feb 6 TC call.
Status changed to closed on Feb 20 TC call.
Review normative RFC 2119 language in WS-SecureConversation
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
Proposal 1 accepted, status changed to pending on Jan 9 TC call.
Status changed to review on Feb 6 TC call.
Status changed to closed on Feb 20 TC call.
Review normative RFC 2119 language in WS-SecurityPolicy
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
Proposal 1 accepted, status changed to pending on Jan 9 TC call.
Status changed to review on Feb 6 TC call.
Status changed to closed on Feb 20 TC call.
Change key to crucial in SC text
The word key is used too many times in the sentences below. I suggest the word “crucial” as a substitute.
ws-sc
spec
editorial
Marc Goodner
Editors
Proposal one accepted, status changed to pending on Oct 31st TC call.
Moved to review on Dec. 12th TC call.
Moved to closed on Jan. 9th TC call.
SecondaryParameters element missing from WS-Trust schema xsd
While reviewing the ws-sx Interop doc scenarios messages for the
examples document and comparing to more recent messages, it was found
that SecondaryParameters had been added to the WS-Trust Specification
properly, but apparently did not also get added to the WS-Trust schema
xsd.
ws-trust
schema
editorial
Rich Levinson
Editors
Proposal one accepted with amendment from Jiadong,
status changed to pending on Nov 28th TC call.
Moved to review on Dec. 12th TC call.
Moved to closed on Jan. 9th TC call.
Conflict Nonce reuse description in the current WS-SC 1.3
Line 796 - 799: It stated that nonce is not recommended to be reused.
The policy presents a method for specifying this information. 796 The
RECOMMENDED approach is to use separate nonces and have independently
generated keys for 797 signing and encrypting in each direction.
Furthermore, it is RECOMMENDED that new keys be derived 798 for each
message (i.e., previous nonces are not re-used).
Where as in Line 886 - 890: It stated that the same nonce should be used
for subsequent derivation.
886 If specified, this optional element specifies a base64 encoded nonce
that is used in the key 887 derivation function for this derived key. If
this isn't specified, it is assumed that the recipient 888 knows the nonce
to use. Note that once a nonce is used for a derivation sequence, the same
889 nonce SHOULD be used for all subsequent derivations.
ws-sc
spec
editorial
Hyen V Chung
Hyen V Chung
Proposal one accepted, status changed to pending on Dec 12th TC call.
Status changed to review on Feb 6 TC call.
Status changed to closed on Feb 20 TC call.
ContentEncryptedElement assertion is not defined in the ws-securitypolicy-1.2.xsd
ContentEncryptedElement assertion is not defined in the ws-securitypolicy-1.2.xsd
ws-sp
schema
editorial
Raised on call
Editors
Add the missing assertion to he schema.
Proposal one accepted, status changed to pending on Nov 28th TC call.
Moved to review on Dec. 12th TC call.
Moved to closed on Jan. 9th TC call.
Chairs to investigate whether a second ballot is required to fix the XPath version number problem.
Done
Chairs to put link to issues list on TC home page.
Done
Frederick Hirsch to craft proposal for the Issue 11 - "WS-SX Charter XPath requirements ...".
Done
Chairs to create a Kavi location for WSDL files.
Done
Marc Goodner to create a new issue and assign to Editors to add the OASIS boilerplate to the XSD and WSDL files.
Done
Chairs to hold a F2F attendance ballot starting Mar 1 and closing at least two weeks before the F2F.
Due to start on March 1st.
Martin Gudgin to post interop document referenced from WS-SecurityPolicy F2F presentation.
Done
Chairs to arrange for a second charter clarification vote.
Done
Editors to check that XPath examples in WS-SecurityPolicy are fully namespace qualified.
Decided this was moot at April 4th F2F
Chris Kaler will reply by email to Issue 014's
questions.
Done
Marc Goodner to work on an initial interop
scenarios document. Prateek Mishra also offered to help.
Done
Heather Hinton and Tony Nadalin to work on an
initial use cases document. Prateek Mishara also offered to help.
Done
Tony Nadalin will look into the possibility of
hosting an interop event at the April F2F location
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.
Chairs to ensure the list of voting members on the
roster is correct.
Chairs to re-run the charter clarification ballot
#2 a second time (after fixing the roster).
Marc Goodner to post WS-SX issue template to TC
site and Chairs to put it in a prominent location to make it easier to
find.
TC members to review the initial interop scenarios
by the Feb 15 TC meeting so that the TC can decide at that meeting
whether the TC has "critical mass" for an Apr F2F interop event.
Gudge to draft a revised proposal for Issue 9
Prateek to give a proposed use case for Issue 10 before
the next call.
Done
C.Y Chao to propose to the TC whether Issue 015 should
be closed or not due to revealing the information might be a security
risk.
Done
Prateek to propose resolution to Issue 20 before F2F
Done
Chairs to add information to the public page on how to
access previous versions of the Issues List.
They are available from
the URI http://docs.oasis-open.org/ws-sx/issues/
Prateek to provide additional broader scenarios for at
least WS-Trust. New ETA is Mar 17.
Done
TC members to come to the April F2F with data on when
they would be ready to carry out SC/Trust interop.
Done at April F2F, see minutes.
Jan Alexander will provide a solution to Issue 41.
Werner Dittman to give an example of a case for
Issue 27 that is not sensible so that we can indicate that some cases do
not make sense. Werner will propose specific change to SP to give
guidance on the problem identified in Issue 27.
Werner Dittman to work with Tony Nadalin to see if
it would be useful to include Tony's UML diagram to clarify Issue 28.
Done
Werner Dittman, Tony Gillotta and Gudge will
prepare a proposal to add some text to describe how to extend token
assertions for Issue 30.
Prateek Mishra to respond to Jan's message re Issue
10.
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
Mike to provide better description(s) and a
complete proposal(s) for issue 016 and issue 018 by the F2F meeting.
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
Werner and Gudge to work on a new proposal for
Issue 27.
Done
Hal to provided a proposal for Issue 32 before Mar
15 meeting.
Done
Frederick to provide alternative proposal for Issue
36 for the Mar 15 meeting.
DONE. See resolution from March 22nd minutes
Jan Alexander to supply clarifying text for Issue
038 before the Mar 22 meeting.
Done
Gudge will provide text to clarify the usage of
"dialect" for Issue 40 for the Mar 15 meeting.
Done
Gudge and Prateek to draft a new section "Guidance on creating New Token Assertions and Token Assertion Extensibility" for review by the TC (for issue 30).
Done
Marc to version the Interop document and to store it in an Interop scenarios document folder.
Done
Gudge will reply to the thread on Issue 030 before
the Mar 22 meeting.
Done
Tony Nadalin to provide information on where the UML generated schema might be more restrictive than the SP schema.
Opened issue 62 to track this action.
Prateek Mishra to expand his additional scenarios to define the message RSTR's for the Bearer Assertion and HoK Assertions and to show where they are actually different.
DONE. See:
http://lists.oasis-open.org/archives/ws-sx/200604/msg00025.html
Gudge owes Prateek a response (to message 82) for issue 33.
Done
Tony Gullota to provide further examples illustrating issue 48 in time for the F2F.
Done
Martin Raepple will provide text for new section from issue 41 before the F2F.
Done
Marc Goodner to update interop doc with resolution of issue 47 as part of merged interop doc.
Done
Chris Kaler to provide advice on minimum acceptable lengths of P-SHA1 inputs for Issue 20.
Frederick to revised wording for Rule 5 re use of multiple signatures for Issue 52.
done
Tony Nadalin to identify possible issues for SecurityPolicy based on the changes proposed for Issue 52.
Jan Alexander and Martin Gudgin to identify possible issues for SecurityPolicy based on creation of the NoProofKey proposed in the solution to Issue 56.
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
Jan Alexander and Tony Nadalin to identify possible issues for WS-Trust's processing model for the changes made for Issue 57.
No issues found. Closed with no action.
Jan Alexander to start a discussion about security considerations and a section about what this means for relying parties re the proposal adopted for Issue 060.
Done. Logged as issue 68.
Marc Goodner with help from Prateek Mishra to create a merged interop scenarios document.
Done
Marc Goodner with help from Prateek Mishra to document interop message flows based on the current version of SC/Trust.
Final tracked
by this AI. Issues being raised to continue progress.
Chairs to check with absent companies on their plans for SC/Trust interop.
Done
Tony Gullotta will start an email discussion about issue 31 and whether it should be broadened to include other token characteristics.
Gudge to propose revised text for the description of sp:BootstrapPolicy for issue 53.
Done
Tony N and Frederick to consider adding batch facilities to SecureConversation as per Issue 64.
For symmetry it would probably be OK, however there don't seem to be any
strong requirements for this. Suggest closing with no action.
Chairs to do further work on a F2F meeting time and location.
First week of October in San Jose hosted by BEA.
Prateek to review the text added per Issue 30 to see if its explains sufficiently how to use the extensibility of SP to describe token characteristics (related to Issue 31).
done
Hal to make a proposal on how to describe the usage of the Username token re Issue 31.
done
Gudge will investigate and start thread on issue 55.
done
Jan is working on a proposal for issue 65, ETA May
10th.
done
Tony will investigate and start thread on issue 67.
See msg
Tony to update pending trust issues by May 10th.
Gudge to update pending schema issues by May 10th.
Gudge will prepare proposal for issue 33.
done
Frederick to work on a new proposal for issue 70.
Chairs to get thread going on interop participation and
find a coordinator
Kelvin to inform OASIS staff of problems with infrastructure used to support the TC.
Kelvin and others addressed these problems with OASIS staff.
SPAM overwhelmed system last week and OASIS is working on it.
Hal will provide reference to BSP requirement related to issue 90.
Gudge to make proposal for issue 90 by end of September
Chairs to initiate public review of documents by notifying TC administrators.
Chairs to cancel TC calls for Nov 22, Dec 20 and Dec 27
Marc and Tony to prepare interop plan for SP
Kelvin to update public TC web pages with Public review info
Marc to delve into TC document organization issues and report back
TC Chairs: 7 days after availability of Trust/SC updates ask OASIS staff to start a committee spec vote and OASIS member vote
TC Chairs: spin up an OASIS submission form for Trust/SC and solicit information as needed from members via the SX email list
TC Chairs: Prepare formal response to PR issues
Chairs to inform OASIS staff of TC decision to take SP to CD and Public Review.
Apropos of issue PR021 disucussion, BEA will send email to the W3C WS-Policy WG informing them of WS-SX TC’s finding regarding the mixing of WS-policy Versions in nested assertions. The email should include a link to the minutes of the WS-WX meeting of February 14, 2007.
Done
Tony Nadalin to review deferred action item 62 and followup on the list with proposed resolution.
Done
Chairs will cancel next week’s call (Apr 25).
Done
Marc Goodner will provide an updated version of the SP specification incorporating resolutions to the 2nd PR
Done
Greg Carpenter will log new issues to ensure that the TC revisits normative language usage in the next revision of specs.
Done
Chairs will request the TC Administrator to start an electronic ballot to modify the WS-SX TC charter
Done
Chairs will check with Tony Nadalin to verify that he intends to log additional issues against the Examples document.
Done
Chairs will cancel May 23rd and June 6th calls.
Done
Add additional Bridge access numbers to the web site and agendas
Done No action required
Editors will create draft errata docs for SX specs using the WSS errata documents as a template
Ongoing. ETA is late July/early August
Marc Goodner: Analyze schema/example discrepancy described in issue i123 and report back to TC
Done
Marc Goodner: Find previous discussion/resolution related to active issue i134 and report back to TC
Done
Marc Goodner: Make a proposal for ER006 to the list.
Done
Chairs to update public website
Done
Chairs cancel meeting next week (June 20)and week of July 4th
Done
Greg will clone issue i37. The current i137 will reference only the examples doc. The cloned issue will reference only SP.
Done
Prateek will seek clarification from Aditya regarding ER005
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.
Hal will propose draft text for the charter change to the deliverables section.
Done
Chairs: Cancel meetings as appropriate to reflect TC decision to continue meeting on a bi-weekly basis until further notice
Done