RE: [ggf-ogsa-sec-wg] Two documents

[Samuel Meder <meder@mcs.anl.gov>]

On Mon, 2003-02-17 at 21:42, Krishna Sankar wrote:
> Hi all,
> 
> 	Read thru the e-mails and the two documents. Here are some of my
> observations (as usual in random order :o)):
> 
> 	I was also lost in the beginning when I saw the documents. But
> as I read thru them carefully (had a lot of time during my
> coast-to-coast flight today) I realized a few things. Both are profiles
> - the application of a specification to some aspects of the grid domain.
> The reason they seem disjoined or surprised us, is because of the lack
> of a security framework and address the wire formats for two features.
> They are an excellent starting point and we need more of them - most
> proably as tech notes/specification expertise and then merged into a
> general security framework. 
> 
> <soap_box>
> 	What we need is a compact, cohesive & coherent security
> framework - architecture and associated infrastructure. The framework
> should address the *core* security services (identity, authC, authZ,
> policies, delegation, firewalls, ...), the operations, porttypes and
> extension points. The serviceData they expose is also very important. 
> 
> 	The OGSI draft is coming out nicely and once it is discussed and
> ratified at GGF7, we could define a security architecture and
> infrastructure based on the OGSI paradigms. We need the security
> service/object system architecture and the infrastructure wire formats
> underneath the architecture. 
> 
> 	Whether it should be a single wg or not is for us to discuss. I
> think the *core* can be developed by a single wg. Remember we are
> talking about the security substrate based on a SOA - specifically web
> service paradigm. 
> 
> 	We also keep in mind the pragmatic aspects - i.e. develop a core
> and then incrementally add more features. One of the discussions I would
> like to have, is with the Globus team, to seek the security requirements
> - short, medium and long term.
> </soap_box>
> 
> 	In the Security Context Document, on Page 7 or so mentions that
> "new xml-elements were defined to render GSSAPI..." but didn't see any
> WS-Trust in the document. Am I missing something ?

We should have been clearer on where we use what standard. The
RequestSecurityToken adn RequestSecurityTokenResponse elements are
defined in WS-Trust. I'll work on this for the next draft.

> 	In the use of SAML ... document, 5th paragraph states "This spec
> does not define a mechanism ... WS-Trust will be used to define this" -
> Am not sure the WS-Trust would define a mechanism. Anyway we can discuss
> later ...
> 
> 	Also the "Use of SAML..." document is a good addition to the
> authZ wg. We have a section for XML protocols and specifications where
> this document would fit in very well.
> 
> 	I think both documents need the PortTypes, operations and the
> serviceData sections. 

The secure conversation profile document actually defines a porttype
(may need more work, but it is a start). We are also working on a
porttype for a authorization service, but it is not quite there yet.

/Sam

> 	May be it is a good idea to have a top level GridSecurityService
> with security operations and securityServiceData. Then the bottoms
> approach can define the services, operations and data based on that
> framework - just a thought.
> 
> cheers
> 	
> 
> > -----Original Message-----
> > From: owner-ogsa-sec-wg@gridforum.org 
> > [mailto:owner-ogsa-sec-wg@gridforum.org] On Behalf Of Michael Helm
> > Sent: Monday, February 17, 2003 10:06 AM
> > To: ogsa-sec-wg@gridforum.org
> > Subject: Re: [ggf-ogsa-sec-wg] Two documents 
> > 
> > 
> > "Olle Mulmo" writes:
> > > list and asked up-front how we are to deal with bottom-up approaches
> > > in this WG (see mail archives), as they will surely appear sooner or
> > 
> > How about "pragmatic" ... bottom-up has strange connotations!
> > 
> > > My non-initiated suggestion is to break this WG into two: a research
> > > group that continues the work on the roadmap, laying out 
> > the long-term,
> > > high-level architecture; and a WG that operates in the web 
> > services space,
> > > discussing the nitty-gritty protocol details of various 
> > service specs.
> > 
> > I think this is an excellent idea.  One of my colleagues has suggested
> > that this is a whole entire area, and should be broken up into
> > a zillion wg's, probably one for every spoke on the famous wagon-wheel
> > slide.  Having gone thru such a transition in another place, I  have
> > some reservations about that.  But a split as Olle described looks
> > helpful.   Some of us are interested in the architecture, but are 
> > unsure what exactly needs to be done ; there are many dependencies
> > in the architecture on things that don't exist in standards bodies
> > that have just begun work, as well as opportunities to do work
> > in areas that look more mature (like xkms or saml).  Decoupling
> > at least releases an inhibition against starting work.
> > 
>