OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


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]