RE: [ws-sx] Issue PR015: Missing issuer and required claims inside token assertions

The reason I ask is we recently added an assertion to 
indicate when not to provide a password with the UsernameToken. I'm wondering if 
that might be better served through this mechanism for 
consistency.

From: Jan Alexander 
[mailto:] 
Sent: Wednesday, January 31, 2007 1:37 
PM
To: Tony Gullotta; Greg Carpenter; 

Cc: Marc Goodner
Subject: RE: 
[ws-sx] Issue PR015: Missing issuer and required claims inside token 
assertions

If 
your claims dialect supports such claim type then yes, 
sure.

 

From: Tony Gullotta 
[mailto:] 
Sent: Wednesday, January 31, 2007 
10:57 AM
To: Greg Carpenter; Jan Alexander; 

Cc: Marc Goodner
Subject: RE: 
[ws-sx] Issue PR015: Missing issuer and required claims inside token 
assertions

 

Could 
the password in a UsernameToken be considered a "claim"?

 

From: Greg Carpenter 
[mailto:] 
Sent: Wednesday, January 31, 2007 
6:01 AM
To: Jan Alexander; 
Cc: 
Marc Goodner
Subject: [ws-sx] Issue PR015: Missing issuer and required 
claims inside token assertions

Issue 
PR015

[Apologies 
if this is a duplicate. The first attempt seems to have disappeared into the 
cloud]

 

From: Jan Alexander 

Sent: Tuesday, January 30, 2007 10:44 PM
To: 

Cc: Marc Goodner; Greg 
Carpenter
Subject: NEW Issue: Missing issuer and required claims 
inside token assertions

 

PLEASE DO NOT REPLY TO THIS 
EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER.  

The issues coordinators will 
notify the list when that has occurred.

Protocol:  ws-securitypolicy

http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/21401/ws-securitypolicy-1.2-spec-cd-01.pdf

Artifact:  spec / schema

Type: design

Title: Missing issuer and required claims inside token 
assertions

Description:

The current WS-SecurityPolicy 
specification does not provide any guidance or explicit support for expressing 
requirement for multiple supporting token of the same type. The main issue is 
that it is not really possible to differentiate between individual tokens if 
they share the same token type and thus matching the actual tokens with the 
token assertions in the receiver’s policy. The only exception is IssuedToken 
assertion, where it is possible to differentiate tokens based on the token 
issuer parameter.

The proposal below adds the 
optional issuer parameter to all token assertions defined in the specification. 
The existing sp:Issuer element as defined for IssuedToken, SpnegoContextToken 
and SecureConversationToken assertions is reused for this purpose. 

In addition to that it adds an 
optional claims parameter that allows the receiver to express required claims 
that have to be present in the token in order for the token to fulfill the token 
assertion requirements. The existing wst:Claims element from WS-Trust Issuance binding is reused for 
this purpose. The wst:Claims element allows the receiver to fine tune the token 
requirements in its policy. 

The proposal below also 
clarifies the rules that govern the matching of the actual security tokens with 
the token assertions.

Related 
issues:

None.

Proposed 
Resolution:

Please see the 
attached document for the proposal.