http://docs.oasis-open.org/ws-sx/issues/
WS-SX TC Issues List
Date: 2006/01/18
Revision: 03
spec
schema
soap
wsdl
policy
all
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
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
Transitive closure spec dependencies
Transitive closure spec dependencies
ws-sc
ws-sp
ws-trust
spec
editorial
First F2F
Paul Cotton
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
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
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
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
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?
ws-trust
spec
design
Prateek Mishra
Prateek Mishra
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
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.
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.
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.
Martin Gudgin to post interop document referenced from WS-SecurityPolicy F2F presentation.
Chairs to arrange for a second charter clarification vote.
Editors to check that XPath examples in WS-SecurityPolicy are fully namespace qualified.