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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

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


Subject: RE: [wss] scenarios for first interop


Hi Chris,


I've some concerns regarding test case 2. Test case 2 requires sending an SHA1(date+nonce+password), but as it has been worked out in several discussions in this list, plain text passwords are not available on all systems. As the test also includes the signature test, it would exclude quite a few
implementations from participation for test 2.

Instead of directly starting with tests combining multiple features, why don't we start with tests verifying the basic features of the SOAP Message security specification. 
Feature tests:

Test 1 (U/PW Text): Send a SOAP message with SecurityHeader including a wsse:PasswordText password
Test 2 (U/PW Digest): Same as #1, but with digested wsse:PasswordDigest PW
Test 3 (Timestamp): Add a timestamp to the SOAP header, check if it is correctly understood.
Test 4 (Timestamp+Delay): Add a timestamp and information from an intermediate. Only based on the timestamp, the message should be delayed; but with the statement of the intermediary about the delay, the message should still be accepted.
Test 5 (Signature 1): Sign the header of the message and a timestamp, return a signed header
Test 6 (Signature 2): Sign the body of the message and a timestamp, return a signed header
Test 7 (Signature 3): Sign parts of the attachments in a Multi-part MIME SOAP message
Test 8 (Signature 4): like 7, but sign all attachments
Test 9 (Encryption 1): Encrypt the body of the message, return an encrypted body
Test 10 (Encryption 1): Encrypt parts of the attachments in a Multi-part MIME SOAP message
Test 11 (Encryption 2): like 11, but all attachments

When these test are successful, we should have some composite tests:

Test 100: Authentication with U/PW, result signed, timestamp signed
Test 101: Authentication using signed header, result encrypted, timestamp included

For later, one could also think about more complex examples, i.e. with multiple SecurityHeaders, parts of the message encrypted to be read by multiple receivers.

Best Regards,
Martijn de Boer
SAP

-----Original Message-----
From: Chris Kaler [mailto:ckaler@microsoft.com]
Sent: Mittwoch, 5. März 2003 11:21
To: Ahmed, Zahid; Web Services Security
Cc: Burdett, David
Subject: RE: [wss] scenarios for first interop


We should make sure we capture these, but my guess is that 1-4 will more
than cover a first interop event and we will likely need to move to a
2nd in order to cover these advanced scenarios as well as flushing out
additional token types (#11 as well as others).

That said, we should get these written up in more detail, along with
1-4, 
and see what people think they can commit to having for a first event.

Chris

-----Original Message-----
From: Ahmed, Zahid [mailto:zahid.ahmed@commerceone.com] 
Sent: Wednesday, March 05, 2003 2:04 AM
To: Chris Kaler; Web Services Security
Cc: Burdett, David

Here are some additional SOAP Message security interop test-cases
that we should consider for the first or second interop event. 
 
I am numbering them after the first four that Chris Kaler has proposed 
just in case we decide to compile these in some interop testing 
document:
 
 
5. Signing and encrypting specific attachments in a Multi-part MIME SOAP

    message.
 
6. Signing and encrypting all attachments in a Multi-part MIME SOAP 
    message.
 
7. Decrypting and verifying signatures of specific attachments in a
Multi-part 
    MIME SOAP message.
 
8. Decrypting and verifying signatures of all the attachments in a
Multi-part MIME 
   SOAP message.
 
9. Signing and encrypting SOAP Body and specific attachment in
Multi-part
MIME
    SOAP message.
 
10. Decrypting and signature verification of content in SOAP Body and
      required attachment in a Multi-part MIME SOAP message.
 
11. SOAP Message Token Processing for X.509 Certificates and SAML 
    Tokens, e.g., for authenticating a sending web service application
by
    a receiving web services applications. 
 
 
Also, #4 is quite important to flesh out in advance for #1 thru #3 and
#5
thru #11.
 
 
thanks,
Zahid Ahmed
Commerce One, Inc.
 

-----Original Message-----
From: Chris Kaler [mailto:ckaler@microsoft.com]
Sent: Monday, March 03, 2003 8:32 AM
To: Web Services Security
Subject: [wss] scenarios for first interop



I had the action to propose some initial scenarios for a first interop

event.  If people like these, I'll add more details like WSDL, example
messages, etc.

 

1. Send message with U/P over SSL and get response

2. Send message with U/P-Hash and get response signed with X.509

3. Send message with X.509 signature and encrypted with key passed

   in EncryptedKey using recipients certificate referenced by identifier

4. Variations on algorithms (C14N, encryption, etc.)

 

Signatures are over key headers and body.  Encryption is only on body.

 

Basically people would implement both clients and servers and then we

would interchange the components.

 

Chris

 

 


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>




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