[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] Proposal for Issue #31 - Richer Username Token Policies
> Notwithstanding my continued scepticism that any of this is necessary, > is there some reason you didn't go with an approach like; > > <sp:UsernameToken> > <wsp:Policy> > <sp:NoPassword /> > ... > </wsp:Policy> > </sp:UsernameToken> > > > <sp:UsernameToken> > <wsp:Policy> > <sp:HashPassword /> > ... > </wsp:Policy> > </sp:UsernameToken> > > where sp:NoPassword and sp:HashPassword set a tri-value property that > defaults to 'plaintext password'. I don't really understand why you'd > create separate token assertions rather than using nested assertions in > this case. I considered that alternative and in fact, decided to merely sketch the approach until there is consensus for that reason. My thinking was that this approach is more consistent with the "top level matching" philosophy of WS-Policy. Personally I would be equally happy with your alternative approach. Esthetically, I agree that artificially creating Token sub-types is ugly. > > Also, did you intend to disallow sp:RequireDerivedKeys et.al. in the > plain-text and hash cases? Yes. In my view there are four cases: 1. Username alone sent under signature linked to some other Token, e.g. X.509. (WS-I Sample apps use this idiom, for example.) 2. Username alone with key derived from password. Ability to verify signature or decrypt data verifies password. Undesirable to send password or hash in message. 3. Username and text password. Password verified directly. Keys derived from password would be exposed. 4. Username and WSS specified hash. Alternative to key derivation, which is not bound to message content. Hal > > Gudge > > > > > -----Original Message----- > > From: Hal Lockhart [mailto:hlockhar@bea.com] > > Sent: 16 May 2006 13:53 > > To: ws-sx@lists.oasis-open.org > > Subject: [ws-sx] Proposal for Issue #31 - Richer Username > > Token Policies > > > > I propose that lines 836-857 be replaced with: > > > > ---- > > /sp:UsernameTokenAlone > > This identifies a UsernameToken assertion with no password or hash > > value. > > /sp:UsernameToken/@sp:IncludeToken > > This optional attribute identifies the token inclusion value for this > > token assertion. > > /sp:UsernameToken/wsp:Policy > > This optional element identifies additional requirements for > > use of the > > sp:UsernameToken assertion. > > /sp:UsernameToken/wsp:Policy/sp:RequireDerivedKeys > > This optional element sets the [Derived Keys], [Explicit Derived Keys] > > and [Implicit Derived Keys] properties for this token to 'true'. > > /sp:UsernameToken/wsp:Policy/sp:RequireExplicitDerivedKeys > > This optional element sets the [Derived Keys] and [Explicit Derived > > Keys] properties for this token to 'true' and the [Implicit Derived > > Keys] property for this token to 'false'. > > /sp:UsernameToken/wsp:Policy/sp:RequireImplicitDerivedKeys > > This optional element sets the [Derived Keys] and [Implicit Derived > > Keys] properties for this token to 'true' and the [Explicit Derived > > Keys] property for this token to 'false'. > > /sp:UsernameToken/wsp:Policy/sp:WssUsernameToken10 > > This optional element indicates that a Username token should > > be used as > > defined in [WSS: Username Token Profile 1.0]. As noted above, this is > > the default version of this token. > > /sp:UsernameToken/wsp:Policy/sp:WssUsernameToken11 > > This optional element indicates that a Username token should > > be used as > > defined in [WSS: Username Token Profile 1.1]. > > > > > > /sp:UsernameTokenPassword > > This identifies a UsernameToken assertion with a text password. > > /sp:UsernameToken/@sp:IncludeToken > > This optional attribute identifies the token inclusion value for this > > token assertion. > > /sp:UsernameToken/wsp:Policy > > This optional element identifies additional requirements for > > use of the > > sp:UsernameToken assertion. > > /sp:UsernameToken/wsp:Policy/sp:WssUsernameToken10 > > This optional element indicates that a Username token should > > be used as > > defined in [WSS: Username Token Profile 1.0]. As noted above, this is > > the default version of this token. > > /sp:UsernameToken/wsp:Policy/sp:WssUsernameToken11 > > This optional element indicates that a Username token should > > be used as > > defined in [WSS: Username Token Profile 1.1]. > > > > > > /sp:UsernameTokenHash > > This identifies a UsernameToken assertion with a hash value. > > /sp:UsernameToken/@sp:IncludeToken > > This optional attribute identifies the token inclusion value for this > > token assertion. > > /sp:UsernameToken/wsp:Policy > > This optional element identifies additional requirements for > > use of the > > sp:UsernameToken assertion. > > /sp:UsernameToken/wsp:Policy/sp:WssUsernameToken10 > > This optional element indicates that a Username token should > > be used as > > defined in [WSS: Username Token Profile 1.0]. As noted above, this is > > the default version of this token. > > /sp:UsernameToken/wsp:Policy/sp:WssUsernameToken11 > > This optional element indicates that a Username token should > > be used as > > defined in [WSS: Username Token Profile 1.1]. > > ---- > > > > Also some editorial changes will be required to the > > introductory text at > > the start of section 5.3.1 and the Syntax block. > > > > Hal > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]