Hola Pablo te copio el policycache.config ya que tengo ciertas dudas:
1) <request policy="#MyPolicy1-Request"></request> Que nombre debería de
poner en lugar de "#MyPolicy1-Request".
2) Debería de eliminar el TAG de <DefaultOperation> ?
3) Debería eliminar el TAG donde dice <request policy=#Sign-Username> y
entonces dejar la descripción para cada uno de mis WebMethods?

Quedo a la espera de tu respuesta,
Gracias

<?xml version="1.0" encoding="utf-8"?>
<policyDocument xmlns="http://schemas.microsoft.com/wse/2003/06/Policy">
 <mappings xmlns:wse="http://schemas.microsoft.com/wse/2003/06/Policy">
   <!--The following policy describes the policy requirements for the
service: http://localhost/Prueba.WebServices/Convenios.asmx .-->
   <endpoint uri="http://localhost/Prueba.WebServices/MiWebService1.asmx">
     <defaultOperation>
       <request policy="#Sign-SCT-Encrypt-SCT" />
       <response policy="#Sign-SCT-Encrypt-SCT-1" />
       <fault policy="" />
     </defaultOperation>
     <operation
requestAction="http://schemas.xmlsoap.org/ws/2004/04/security/trust/RST/SCT">
       <!--RST and RSTR messages are being processed by WSE policy engine
similar to other messages. If a service policy mapping
        specifies policies that use SCT token for defaultOperation, there MUST be
a separate mapping for RST/RSTR messages.
        Policies specified for RST/RSTR messages can be empty. In addition to the
policy specified for RST and RSTR messages,
        WSE infrastructure will enforce and verify that:
            1. RST Enforcement: An RST message will be signed using baseToken. If an
Issuer Token is present, an entropy will be created and encrypted
              using the Issuer Token. If a UsernameToken is used in the message it
will be encrypted using the Issuer Token.
            2. RST Verification: An RST message must be signed. If the RST contains
an entropy, it must be encrypted by the server token.
              If a UsernameToken was used in the message it must be encrypted.
            3. RSTR Enforcement: An RSTR message will be signed using the server
token. If the client used entropy in the RST message, a server entropy
              will be created and encrypted with client's entropy token. If a
Username token is used in the message it will be encrypted
              with the client's entropy token.
            4. RSTR Verification: An RSTR message must be signed using the Server
Token. If an entropy is used it must be encrypted using client's
              entropy token. If a username token is issued in the RSTR message it
must be encrypted.
        Implement a custom SecurityContextTokenService or
SecurityContextTokenServiceClient to change the policy enforcement
        and/or verification behaviors.
        -->
       <request policy="#Sign-Username" />
       <response policy="" />
       <fault policy="" />
     </operation>
   </endpoint>
 </mappings>
 <policies
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy"
xmlns:wssp="http://schemas.xmlsoap.org/ws/2002/12/secext"
xmlns:wse="http://schemas.microsoft.com/wse/2003/06/Policy"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
   <wsp:Policy wsu:Id="Sign-SCT-Encrypt-SCT">
     <!--MessagePredicate is used to require headers. This assertion should
be used along with the Integrity assertion when the presence of the signed
element is required. NOTE: this assertion does not do anything for
enforcement (send-side) policy.-->
     <wsp:MessagePredicate wsp:Usage="wsp:Required"
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()
wsp:Header(wsa:To) wsp:Header(wsa:Action) wsp:Header(wsa:MessageID)
wse:Timestamp()</wsp:MessagePredicate>
     <!--The Integrity assertion is used to ensure that the message is
signed with SCT. Many Web services will also use the token for authorization,
such as by using the <wse:Role> claim or specific SCT claims.-->
     <wssp:Integrity wsp:Usage="wsp:Required">
       <wssp:TokenInfo>
         <!--The SecurityToken element within the TokenInfo element
describes which token type must be used for Signing.-->
         <wssp:SecurityToken>
           
<wssp:TokenType>http://schemas.xmlsoap.org/ws/2004/04/security/sc/dk</wssp:TokenType>
           <wssp:Claims>
             <wse:Parent>
               <wssp:SecurityToken wse:IdentityToken="true">
                 
<wssp:TokenType>http://schemas.xmlsoap.org/ws/2004/04/security/sc/sct</wssp:TokenType>
                 <wssp:Claims>
                   <wse:BaseToken>
                     <wssp:SecurityToken>
                       
<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1
.0#UsernameToken</wssp:TokenType>
                       <wssp:Claims>
                         <!--By specifying the Role, the policy system can
verify that the token contains a specific role, such as "Admin". Roles can be
groups a user is a member of, or they can be customized for each token.-->
                         <wse:Role value="wsdesa\BancoPopular" />
                       </wssp:Claims>
                     </wssp:SecurityToken>
                   </wse:BaseToken>
                   <wse:IssuerToken>
                     <wssp:SecurityToken>
                       
<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X
509v3</wssp:TokenType>
                       <wssp:TokenIssuer>CN=Root Agency</wssp:TokenIssuer>
                       <wssp:Claims>
                         <!--By specifying the SubjectName claim, the
policy system can look for a certificate with this subject name in the
certificate store indicated in the application's configuration, such as
LocalMachine or CurrentUser. The WSE X.509 Certificate Tool is useful for
finding the correct values for this field.-->
                         <wssp:SubjectName
MatchType="wssp:Exact">CN=WSE2QuickStartServer</wssp:SubjectName>
                         <wssp:X509Extension OID="2.5.29.14"
MatchType="wssp:Exact">bBwPfItvKp3b6TNDq+14qs58VJQ=</wssp:X509Extension>
                       </wssp:Claims>
                     </wssp:SecurityToken>
                   </wse:IssuerToken>
                 </wssp:Claims>
               </wssp:SecurityToken>
             </wse:Parent>
           </wssp:Claims>
         </wssp:SecurityToken>
       </wssp:TokenInfo>
       <wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()
wsp:Header(wsa:Action) wsp:Header(wsa:FaultTo) wsp:Header(wsa:From)
wsp:Header(wsa:MessageID) wsp:Header(wsa:RelatesTo) wsp:Header(wsa:ReplyTo)
wsp:Header(wsa:To) wse:Timestamp()</wssp:MessageParts>
     </wssp:Integrity>
     <!--The Confidentiality assertion is used to ensure that the SOAP Body
is encrypted.-->
     <wssp:Confidentiality wsp:Usage="wsp:Required">
       <wssp:KeyInfo>
         <!--The SecurityToken element within the KeyInfo element describes
which token type must be used for Encryption.-->
         <wssp:SecurityToken>
           
<wssp:TokenType>http://schemas.xmlsoap.org/ws/2004/04/security/sc/dk</wssp:TokenType>
           <wssp:Claims>
             <wse:Parent>
               <wssp:SecurityToken wse:IdentityToken="true">
                 
<wssp:TokenType>http://schemas.xmlsoap.org/ws/2004/04/security/sc/sct</wssp:TokenType>
                 <wssp:Claims>
                   <wse:BaseToken>
                     <wssp:SecurityToken>
                       
<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1
.0#UsernameToken</wssp:TokenType>
                       <wssp:Claims>
                         <!--By specifying the Role, the policy system can
verify that the token contains a specific role, such as "Admin". Roles can be
groups a user is a member of, or they can be customized for each token.-->
                         <wse:Role value="wsdesa\BancoPopular" />
                       </wssp:Claims>
                     </wssp:SecurityToken>
                   </wse:BaseToken>
                   <wse:IssuerToken>
                     <wssp:SecurityToken>
                       
<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X
509v3</wssp:TokenType>
                       <wssp:TokenIssuer>CN=Root Agency</wssp:TokenIssuer>
                       <wssp:Claims>
                         <!--By specifying the SubjectName claim, the
policy system can look for a certificate with this subject name in the
certificate store indicated in the application's configuration, such as
LocalMachine or CurrentUser. The WSE X.509 Certificate Tool is useful for
finding the correct values for this field.-->
                         <wssp:SubjectName
MatchType="wssp:Exact">CN=WSE2QuickStartServer</wssp:SubjectName>
                         <wssp:X509Extension OID="2.5.29.14"
MatchType="wssp:Exact">bBwPfItvKp3b6TNDq+14qs58VJQ=</wssp:X509Extension>
                       </wssp:Claims>
                     </wssp:SecurityToken>
                   </wse:IssuerToken>
                 </wssp:Claims>
               </wssp:SecurityToken>
             </wse:Parent>
           </wssp:Claims>
         </wssp:SecurityToken>
       </wssp:KeyInfo>
       <wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()</wssp:MessageParts>
     </wssp:Confidentiality>
   </wsp:Policy>
   <wsp:Policy wsu:Id="Sign-SCT-Encrypt-SCT-1">
     <!--MessagePredicate is used to require headers. This assertion should
be used along with the Integrity assertion when the presence of the signed
element is required. NOTE: this assertion does not do anything for
enforcement (send-side) policy.-->
     <wsp:MessagePredicate wsp:Usage="wsp:Required"
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()
wsp:Header(wsa:To) wsp:Header(wsa:Action) wsp:Header(wsa:MessageID)
wse:Timestamp()</wsp:MessagePredicate>
     <!--The Integrity assertion is used to ensure that the message is
signed with SCT. Many Web services will also use the token for authorization,
such as by using the <wse:Role> claim or specific SCT claims.-->
     <wssp:Integrity wsp:Usage="wsp:Required">
       <wssp:TokenInfo>
         <!--The SecurityToken element within the TokenInfo element
describes which token type must be used for Signing.-->
         <wssp:SecurityToken>
           
<wssp:TokenType>http://schemas.xmlsoap.org/ws/2004/04/security/sc/dk</wssp:TokenType>
           <wssp:Claims>
             <wse:Parent>
               <wssp:SecurityToken wse:IdentityToken="true">
                 
<wssp:TokenType>http://schemas.xmlsoap.org/ws/2004/04/security/sc/sct</wssp:TokenType>
               </wssp:SecurityToken>
             </wse:Parent>
           </wssp:Claims>
         </wssp:SecurityToken>
       </wssp:TokenInfo>
       <wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()
wsp:Header(wsa:Action) wsp:Header(wsa:FaultTo) wsp:Header(wsa:From)
wsp:Header(wsa:MessageID) wsp:Header(wsa:RelatesTo) wsp:Header(wsa:ReplyTo)
wsp:Header(wsa:To) wse:Timestamp()</wssp:MessageParts>
     </wssp:Integrity>
     <!--The Confidentiality assertion is used to ensure that the SOAP Body
is encrypted.-->
     <wssp:Confidentiality wsp:Usage="wsp:Required">
       <wssp:KeyInfo>
         <!--The SecurityToken element within the KeyInfo element describes
which token type must be used for Encryption.-->
         <wssp:SecurityToken>
           
<wssp:TokenType>http://schemas.xmlsoap.org/ws/2004/04/security/sc/dk</wssp:TokenType>
           <wssp:Claims>
             <wse:Parent>
               <wssp:SecurityToken wse:IdentityToken="true">
                 
<wssp:TokenType>http://schemas.xmlsoap.org/ws/2004/04/security/sc/sct</wssp:TokenType>
               </wssp:SecurityToken>
             </wse:Parent>
           </wssp:Claims>
         </wssp:SecurityToken>
       </wssp:KeyInfo>
       <wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()</wssp:MessageParts>
     </wssp:Confidentiality>
   </wsp:Policy>
   <wsp:Policy wsu:Id="Sign-Username">
     <!--MessagePredicate is used to require headers. This assertion should
be used along with the Integrity assertion when the presence of the signed
element is required. NOTE: this assertion does not do anything for
enforcement (send-side) policy.-->
     <wsp:MessagePredicate wsp:Usage="wsp:Required"
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()
wsp:Header(wsa:To) wsp:Header(wsa:Action) wsp:Header(wsa:MessageID)
wse:Timestamp()</wsp:MessagePredicate>
     <!--The Integrity assertion is used to ensure that the message is
signed with Username. Many Web services will also use the token for
authorization, such as by using the <wse:Role> claim or specific Username
claims.-->
     <wssp:Integrity wsp:Usage="wsp:Required">
       <wssp:TokenInfo>
         <!--The SecurityToken element within the TokenInfo element
describes which token type must be used for Signing.-->
         <wssp:SecurityToken>
           
<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1
.0#UsernameToken</wssp:TokenType>
           <wssp:Claims>
             <!--By specifying the Role, the policy system can verify that
the token contains a specific role, such as "Admin". Roles can be groups a
user is a member of, or they can be customized for each token.-->
             <wse:Role value="wsdesa\BancoPopular" />
           </wssp:Claims>
         </wssp:SecurityToken>
       </wssp:TokenInfo>
       <wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()
wsp:Header(wsa:Action) wsp:Header(wsa:FaultTo) wsp:Header(wsa:From)
wsp:Header(wsa:MessageID) wsp:Header(wsa:RelatesTo) wsp:Header(wsa:ReplyTo)
wsp:Header(wsa:To) wse:Timestamp()</wssp:MessageParts>
     </wssp:Integrity>
   </wsp:Policy>
 </policies>
</policyDocument>