I think that this is analogous to the issue
Prateek raised last week:
http://www.oasis-open.org/apps/org/workgroup/ws-sx/email/archives/200605/msg00054.html
Putting the issue in more generic terms: “Should
SP specify additional information that the sender needs, but which is not
explicitly called out by the WSS UTP?”
My inclination is to draw the line at the
choices explicit in the underlying specs, in effect agreeing with Gudge.
http://www.oasis-open.org/apps/org/workgroup/ws-sx/email/archives/200605/msg00060.html
Hal
From: Anthony Nadalin
[mailto:drsecure@us.ibm.com]
Sent: Wednesday, June 07, 2006
8:13 AM
To: Hal
Lockhart
Cc: Martin Gudgin;
ws-sx@lists.oasis-open.org
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
"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
> >
> >