RE: [ws-sx] Issue i142: Examples 2.2.3 and 2.2.4 are miss-labeled

["Symon Chang" <sychang@bea.com>]

I agree with Rich on the fact that these two policy examples do not
explicitly require the use of WS-SecurityConversation. Further more, the
<sp:Trust13> assertion is not necessary for these two policies. 

Looking into Policy Example 2.3.2.4 on page 75 of the Example Document,
it has similar symmetric binding that uses <sp:X509Token> assertion with
<sp:RequireDerivedKeys/>. This policy does not have <sp:Trust13>
assertion. 

The <sp:Trust13> assertion in both Examples 2.2.3 and 2.2.4 should be
removed for simplicity.  

Best regards, 



Symon Chang
BEA Systems Inc. 
 


-----Original Message-----
From: Rich Levinson [mailto:rich.levinson@oracle.com] 
Sent: Tuesday, August 07, 2007 7:49 PM
To: Greg Carpenter
Cc: Hal Lockhart; ws-sx@lists.oasis-open.org; Marc Goodner
Subject: Re: [ws-sx] Issue i142: Examples 2.2.3 and 2.2.4 are
miss-labeled

I have spent some time looking over this issue and will propose some
changes. However, there are a couple of points that I think need to
be on the table before a final decision is made.

 1. While both scenarios do "require the use of mechanisms (e.g. 
DerivedKeyToken)
    defined in WS-SecureConversation" the policies themselves do not 
explicitly require
    the use of WS-SecureConversation per se', which I think generally 
would be
    indicated by specifying an  sp:SecureConversationToken assertion.
 2. The text does incorrectly reference the EncryptedKey mechanism as 
being WSS1.1
    specific, however, I think the intent was actually reference the 
WSS1.1 #EncryptedKey
    SecurityTokenReference mechanism, which is what is used in the 
sample messages and
    meets the WSS11 policy requirement for the 
sp:MustSupportRefEncryptedKey assertion.
 3. While I do not believe the policies explicitly require the use of 
WS-SecureConversation,
    except for the derived key mechanism mentioned above, it is true 
that the examples both,
    in fact, are WS-SecureConversation examples, which is due to the 
fact that they were
    taken from the WCF Interop.

Bottom line: I do not believe the sections are actually mislabeled, 
however, I do think
the text needs some cleanup to indicate that the wss11 requirement is 
the SecurityTokenReference
mechanism and to explicitly note that the example messages do use 
WS-SecureConversation,
but that this is not explicitly required.

I will submit the above changes for consideration and if there are more 
aspects to this issue that
need discussion, then we will move from there.

  Thanks,
  Rich


Greg Carpenter wrote:
> Issue i142.
>
>   
>> -----Original Message-----
>> From: Hal Lockhart [mailto:hlockhar@bea.com]
>> Sent: Monday, July 02, 2007 12:47 PM
>> To: ws-sx@lists.oasis-open.org
>> Cc: Marc Goodner
>> Subject: [ws-sx] New Issue: Examples 2.2.3 and 2.2.4 are miss-labeled
>>
>> PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL
>> THE ISSUE IS ASSIGNED A NUMBER.
>> The issues coordinators will notify the list when that has occurred.
>>
>> Protocol:  ws-sp examples
>>
>>
http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/24008/ws
>> -sp-usecases-examples-draft-14-02.doc
>>
>>
>> Artifact:  examples
>>
>> Type:
>>
>> editorial
>>
>> Title:
>>
>> Examples 2.2.3 and 2.2.4 are miss-labeled
>>
>> Description:
>>
>> Examples 2.2.3 and 2.2.4 are identified as being based on WSS 1.1.
>> However, both require the use of mechanisms (e.g. DerivedKeyToken)
>> defined in WS-SecureConversation.
>>
>> The text refers to EncryptedKey as a WSS 1.1 feature, but
EncryptedKey
>> is defined by XML Enc and has been present in WSS since version 1.0.
I
>> am not sure if there is any dependency of these examples on WSS 1.1,
but
>> surely their use of WS-SecureConversation is a much more significant
>> difference between them and the prior examples.
>>
>> Related issues:
>>
>> None
>>
>> Proposed Resolution:
>>
>> Modify the titles of these examples to make it clear that they are
>> examples of the use of WS-SecureConversation, not (just) WSS 1.1.
>>     

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.