[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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:janalex@microsoft.com] Sent: Wednesday, January 31, 2007 1:37 PM To: Tony Gullotta; Greg Carpenter; ws-sx@lists.oasis-open.org 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:tony.gullotta@soa.com] Could
the password in a UsernameToken be considered a "claim"? From: Greg Carpenter
[mailto:gregcarp@microsoft.com] Issue
PR015 [Apologies
if this is a duplicate. The first attempt seems to have disappeared into the
cloud] From: Jan Alexander
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 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]