[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 93: Need a holder for token assertions within the SupportingTokens assertions
Sorry for being slow, this is
issue 93. From: Tony Gullotta
[mailto:tony.gullotta@soa.com] 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 thesupporting 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]