Issue 93: Need a holder for token assertions within the SupportingTokens assertions

Sorry for being slow, this is
issue 93.

 

From: Tony Gullotta
[mailto:] 

Sent: Friday, July 21, 2006 1:02 PM

To: 

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