http://docs.oasis-open.org/ws-sx/issues/
WS-SX TC Issues List
Date: 2006/05/31
Revision: 28
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
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
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.
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.
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.
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
DClosed 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
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
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.
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 recieving 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.
i060
AI-2006-05-03-02
SecurityPolicy use cases
SecurityPolicy use cases
ws-sp
spec
design
Ashok Malhotra
Ashok Malhotra
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
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.
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
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
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.
In progress, most message flows and XML examples are present in current
draft.
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.
Please provide any conflicts and preferred locations for a F2F in October to Chris and Kelvin.
Second week of October most likely. Noted possible conflicts with
Columbus Day and Canadian Thanksgiving.
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.
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