http://docs.oasis-open.org/ws-sx/issues/
WS-SX TC Issues List
Date: 2006/09/29
Revision: 50
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:
msg00016
msg00044
msg00050
ws-trust
spec
design
Prateek Mishra
Prateek Mishra
Proposal 1 accepted on March 15th TC call.
Revision 4 of Trust contains resolution for review.
Moved to Closed at April 4th F2F.
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.wsdl
oasis-wssx-ws-secureconversation.xsd
Proposal 1 accepted at Jan 18th TC call, status changed to review.
Moved to closed at Jan 25th TC call.
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 discussion
msg00081
msg00083
ws-sp
spec
design
Werner Dittmann
Werner Dittmann
Revised from original.
Proposal 1 accepted with ammendmets on June 7th TC call.
Revision 7 of SP contains resolution for review.
Accepted edits as applied.
AI-2006-04-12-01
AI-2006-04-12-02
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 discussion
msg00071
msg00082
ws-sp
spec
editorial
Prateek Mishra
Prateek Mishra
Add the following sentence to Sections 7.4 (at end of first paragraph) and 7.5 (at end of first paragraph):
Use of this binding assertion implies that the following tokens, if
present in the security header of the request or response message, MUST
be encrypted: timestamp, Supporting tokens and SignedSupporting tokens.
Proposal 2 accepted on May 31st TC call.
Revision 7 of SP contains resolution for review.
Accepted edits as applied.
AI-2006-03-29-01
AI-2006-05-10-01
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 discussion
msg00080
msg00085
ws-sp
spec
design
Tony Gullotta
Tony Gullotta
Add AsymmetricBindingAssertion and SymmetricBindingAssertion to section A.2.
Proposal 5 accepted on May 31st TC call.
Revision 7 of SP contains resolution for review.
Accepted edits as applied.
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.
ws-trust
schema
editorial
AI-2006-03-22-01
Tony Nadalin
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
ws-sp
spec
design
Ashok Malhotra
Ashok Malhotra
Updated from original proposal.
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.
ws-sp
policy
design
Frederick Hirsch
Frederick Hirsch
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.
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.
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
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
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
ws-sp
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.
i078
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.
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.
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
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