ws-sx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: NEW Issue: Need a holder for token assertions within the SupportingTokens assertions
- From: "Tony Gullotta" <tony.gullotta@soa.com>
- To: <ws-sx@lists.oasis-open.org>
- Date: Fri, 21 Jul 2006 13:02:17 -0700
PLEASE DO NOT
REPLY TO THIS EMAIL OR START A DISCUSSION THREAD UNTIL THE ISSUE IS ASSIGNED A
NUMBER.
The issues
coordinators will notify the list when that has
occurred.
Protocol: ws-sp
Artifact: spec
Type:
design
Title:
Need a
holder for token assertions within the SupportingTokens assertions
Description:
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. Here is
some text from the spec:
/sp:SignedSupportingTokens
This identifies a
SignedSupportingTokens assertion. The specified tokens populate the [Signed
Supporting Tokens] property.
/sp:SignedSupportingTokens/wsp:Policy
This describes
additional requirements for satisfying the SignedSupportingTokens
assertion.
/sp:SignedSupportingTokens/wsp:Policy/[Token Assertion]
The policy MUST
identify one or more token assertions.
/sp:SignedSupportingTokens/wsp:Policy/sp:AlgorithmSuite
This optional
element follows the schema outlined in Section 7.1 and describes the algorithms
to use for ...
I would think that as is the case with the binding
assertions, there could be choices for the tokens to be used (SAML vs.
Username). In the binding assertions there is an assertion (i.e.,
InitiatorToken, ProtectionToken, etc.) that is placed at this level so that a
ExactlyOne assertion can be used beneath it for defining the choices. The way
SupportingTokensAssertions are written up now, it isn't clear how that could be
done.
Related issues: None
Proposed
Resolution:
I propose a new assertion that can be used in
the supporting tokens assertion types. The assertion could be named
TokenType. This assertion would be at the first level below the supporting
tokens assertion and it would have its own nested policy for the actual tokens
themselves. This would be similar to the binding assertions. So it would look
something like this:
/sp:SignedSupportingTokens
This identifies a
SignedSupportingTokens assertion. The specified tokens populate the [Signed
Supporting Tokens] property.
/sp:SignedSupportingTokens/wsp:Policy
This describes
additional requirements for satisfying the SignedSupportingTokens
assertion.
/sp:SignedSupportingTokens/wsp:Policy/sp:TokenType
The policy MUST identify
one TokenType assertion.
/sp:SignedSupportingTokens/wsp:Policy/sp:TokenType/wsp:Policy
The policy contained here
MUST identify one or more token assertions.
/sp:SignedSupportingTokens/wsp:Policy/sp:AlgorithmSuite
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]