[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 insidetoken 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]