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

["Krishna Sankar" <ksankar@cisco.com>]

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 ?

	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. 

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