Steven, I wasn't on the call, so others might need to clarify, but I would answer your question as follows. A WS-I PB plus WS-I WSSE Profile client would also have to understand these sections of the OGSA BP, in order to understand the meaning of the ogsabp QNames, and WS-Addressing, which is also profiled in OGSA BP (as are the specific parts of WS-I WSSE Profile that need to be understood). If we have done our homework correctly, everything you need to know is either in OGSA BP or referenced by it. On 7 Apr 2005, at 11:48, Steven Newhouse wrote:
<snip>
2. Namespaces ogsa-bp: a Namespace URI for the Basic Profile 1.0 document (OGSA Basic Profile 1.0) And this note also uses the following entity references to ease the description of the URIs. &wsse; the Namespace URI for Web Services Security v1.0 &ogsabp; the Namespace URI for OGSA Basic Profile 1.0 3. Example The following shows an example which the profile is intended to define. (001) <wsa:EndpointReference> (002) <wsa:Address>http://www.globus.org/some/path</wsa:Address> (003) <wsa:Metadata> (004) <ogsabp:EndpointKeyInfo> (005) <wsse:SecurityTokenReference ogsabp:KeyUsage="&ogsabp;#signature"> (006) <wsse:Reference URI="#token1"/> (007) </wsse:SecurityTokenReference> (008) <wsse:SecurityTokenReference (009) ogsabp:KeyUsage="&ogsabp;#encryption"> (010) <wsse:Embedded> (011) <wsse:BinarySecurityToken ValueType="&wsse;X509PKIpathv1"> (012) MIIC..... (013) </wsse:BinarySecurityToken> (014) </wsse:Embedded> (015) </wsse:SecurityTokenReference> (016) </ogsabp:EndpointKeyInfo> (017) </wsa:Metadata> (018) </wsa:EndpointReference> (001)-(018) An example wsa:EndointReference (004)-(016) An example of ogsabp:EndpointKeyInfo elment is shown. The actual key information contained in the ogsabp:EndpointKeyInfo element is bound to the endpoint specified by the enclosing wsa:EndpointReference. (005)-(007) An example of actual key information is shown. The key is expressed by using wsse:SecurityTokenReference and the ogsabp:KeyUsage attribute shows that the key shoud be used for signature. The key data is referenced by the same document referece, "#token1". (008)-(015) Another example of key information is shown. The key is also expressed by using wsse:SecurityTokenReference, but the actual key data is embbeded in the element as a wsse:BinarySecurityToken in wsse:Embedded. And the usage of the key is specified as encryption by the ogsabp:KeyUsage attribute.
6. Interoperability To ensure the interoperability, a wsse:SecurityTokenReference element MUST comform to the requirements defined in the section 4.2 of the WS-I Basic Profile 1.0 document (SecurityTokenReferences). To ensure the interoperability, if the wsse:BinarySecurityToken refers to or embeds an X509 Certificate, the wsse:BinarySecurityToken MUST comform to the requirements defined in the chapter 6 of the WS-I Basic Profile 1.0 document (X509 Certificate Token Profile).
If I have a client environment that just understands WS-I specifications... what else would it need to understand to support this proposed profile. Could it handle the parsing of ogsabp:KeyUsage and know what to do with it?
Steven
-- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK
-- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)