RE: [ws-sx] Issue 93: Need a holder for token assertions within the SupportingTokens assertions

["Martin Gudgin" <mgudgin@microsoft.com>]

Tony,

 

I believe that the current spec supports what you want;

 

<sp:SignedSupportingTokens>

 <wsp:Policy>

   <wsp:ExactlyOne>

     <sp:UsernameToken> ... </sp:UsernameToken>

     <sp:SamlToken> .. </sp:SamlToken>
   </wsp:ExactlyOne>

   ...

 </wsp:Policy>

</sp:SignedSupportingTokens>

 

Note that one *could* do the same for a protection token (or any of the other token usages we have in the bindings ).

 

<sp:SymmetricBinding>

 <wsp:Policy>

  <sp:ProtectionToken>

   <wsp:ExactlyOne>

    <sp:KerberosToken>

    ...

    </sp:KerberosToken>

    <sp:IssuedToken>
    ...
    </sp:IssuedToken>
   </wsp:ExactlyOne>

  </sp:ProtectionToken>

  ...

 </wsp:Policy>

</sp:SymmetricBinding>

 

Gudge

---

From: Marc Goodner [mailto:mgoodner@microsoft.com]
Sent: 24 July 2006 22:46
To: Tony Gullotta; ws-sx@lists.oasis-open.org
Subject: [ws-sx] 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]
Sent: Friday, July 21, 2006 1:02 PM
To: ws-sx@lists.oasis-open.org
Cc: Marc Goodner
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 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