OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

[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


Hal, password could be just about anything in a UNT, could be a OTP, seems we would want a way to describe the type of password required.

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Inactive hide details for "Hal Lockhart" <hlockhar@bea.com>"Hal Lockhart" <hlockhar@bea.com>


          "Hal Lockhart" <hlockhar@bea.com>

          05/17/2006 09:23 AM


To

"Martin Gudgin" <mgudgin@microsoft.com>, <ws-sx@lists.oasis-open.org>

cc


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
> >
> >

GIF image



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]