[ogsa-wg] OGSA Basic Profile Telecon Agenda 4/6

[Takuya Mori]

Hi Steven,

In general, as David says, your client needs to know the OGSA BP 
specifications and other specifications which is referenced 
by the OGSA BP specs.

With regard to the proposed ogsabp:EndpointKeyInfo and 
ogsabp:KeyUsage, the XML-Signature, WS-Security and WS-Addressing 
speficifations are refferenced and the OGSA Basic Profile will
profile these specifications, so your client needs to know all
of them.

The proposed profile only states where to find a key-info for
message level security and how it is encoded, so I think we
need to state how to handle with the information more clearly.

Thanks,
>From

Takuya: David Snelling <David.Snelling at UK.Fujitsu.com>
Subject: Re: [ogsa-wg] OGSA Basic Profile Telecon Agenda 4/6
Date: Thu, 7 Apr 2005 13:42:55 +0100

> 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)
>