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


I would agree on your recomendation.

-----------------
Sent from Tony's BlackBerry.


----- Original Message -----
From: "Martin Gudgin" [mgudgin@microsoft.com]
Sent: 05/30/2006 11:18 AM
To: "Tony Gullotta" <tony.gullotta@soa.com>; "Hal Lockhart" <hlockhar@bea.com>; <ws-sx@lists.oasis-open.org>
Subject: RE: [ws-sx] Proposal for Issue #31 - Richer Username Token Policies

Tony,

Thanks for the support :-)

However, my real proposal for this issue is to close it with no action.

Cheers

Gudge

> -----Original Message-----
> From: Tony Gullotta [mailto:tony.gullotta@soa.com]
> Sent: 17 May 2006 17:54
> To: Martin Gudgin; Hal Lockhart; ws-sx@lists.oasis-open.org
> Subject: RE: [ws-sx] Proposal for Issue #31 - Richer Username
> Token Policies
>
> I prefer the nested approach Gudge suggests.
>
> -----Original Message-----
> From: Martin Gudgin [mailto:mgudgin@microsoft.com]
> Sent: Tuesday, May 16, 2006 10:10 PM
> To: Hal Lockhart; ws-sx@lists.oasis-open.org
> Subject: RE: [ws-sx] Proposal for Issue #31 - Richer Username Token
> Policies
>
> Hal,
>
> 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.
>
> Also, did you intend to disallow sp:RequireDerivedKeys et.al. in the
> plain-text and hash cases?
>
> 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]