Dane, Thanks for your comments
and kicking off the discussions about enhancement be made to the arch document.
I would like to add my opinion
below in blue.. between the tags <raj>.
We should start taking a
stab at who is going to contribute to which part, and who the volunteers
are. Based on the note below, I think we identified
1. interaction diagram(s)
that show cases the security components identified in the doc
2. usage scenario - if current
needs to be changed, and if so, something that depicts end to end security
model based on any exisiting OGSA-WG scenarios maybe.
Given that the comments
may range from high level suggestions like Dane suggested all the way to
editorial changes that we may encounter, we should probably start tracking
these "work items" under the GridForge tracker.
Thanks
Raj
Dane Skow <dane@fnal.gov> Sent by: owner-ogsa-sec-wg@gridforum.org
04/05/2004 05:19 PM
To
Nataraj Nagaratnam/Raleigh/IBM@IBMUS
cc
ogsa-sec-wg@ggf.org
Subject
Re: [ggf-ogsa-sec-wg] Working
towards the WG deliverables: archtitecture and roadmap
Nataraj Nagaratnam wrote:
> The primary outcome of the OGSA Security WG were to be two documents:
>
> 1. "The Security Architecture for Open Grid Services":
This
> document will describe a security architecture
intended to be
> consistent with the security model that is currently
being
> defined for the Web Services framework used to
realize OGSA's
> service-oriented architecture.
>
To my mind this is the critical document (the roadmap falls out of this
and where people
vote with their feet on what they're willing to work on).
The relevant documents for this Security Architecture to integrate in
with then would
seem to be the OGSA Draft Recommendations document (current version
available at
https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-spec/en/14)
and the Web Services Architecture document (http://www.w3.org/TR/ws-arch/).
Both of these are aimed at a more specific architecture description than
that attempted
by the current draft Informational document. However,
if we're aiming more at a Recommendations level description in enough
detail
that would allow for tests as to whether or not something was "OGSA
compliant" (what I
read in the abstract),
then I think we have some top-level structural changes ahead for the
document. Which
way do folks want to go ?
<raj> I think we should
aim for recommendations level .. so, I think we should address comments/issues/suggestions
from you and others may have. </raj>
To my mind the current draft splits neatly into 3rds: p1-9 are
introduction, p10-22
are the model/architecture, p22-28 are context. What portions of the
intro still need
to be kept now that OGSA is no longer just a potential architecture ?
Can/should
the requirements be referenced to other GGF documents ? Is the challenge
discussion
necessary at all ? (can we presume that this document is to be read
after the OGSA
architecture document ?)
<raj>
I think it is useful to have
the security requirements explicitly in this security architecture document
as well. This is for continuity, self containment as well as comments I
have received from many people in the past indicate that this structure
of containing the requirements within the document helps link the relevance
of the proposed architecture. In a recent mail exchange in the ogsa
wg, it points out that "..
the two primary goals of the OGSA WG are to identify required capabilities
for fundamental Grid services and to translate those capabilities into
a proposed architecture: a coherent set of components that collectively
define the Open Grid Services Architecture",
so, I think we should leave the requirements in there, and add as necessary.
</raj>
I would propose the immediate discussion focus on the central section on
fleshing out
the model. Is it correct to consider the 9 subsections of Section 6 to
be the authors proposed
major components of the model ? At a high level, I don't see a clear
description of how these
components interact in the draft. Figure 2 seems to pull in a number of
other elements. Can someone elaborate on what's intended here ?
<raj>
What was originally intended
is to point out the components that make up the architecture - the diagram
illustrate that those component play a role both on the requestor side
as well as the provider side (or client side and server side respectively).
That said, like we had discussed before during the F2F or one of the phone
calls, adding a section on how these components interact with each other
(if they do), or position them on where they are relevant would be a good
thing to show the usage. It need not be the only usage or interaction,
but atleast capture the most common ones that we can all agree so that
these boxes end up with some semantics wrt a request flow.
</raj>
For the usage scenarios, the OGSA-WG has spent a lot of time on scenario
development.
Should we use/reference/expand one of those for the security example ?
Is that need
already being addressed and thus can be removed from this document ? Is
it sufficient ?
As another source of scenarios being used for pedagogy,
the Web Services Interoperability group have recently released their
first draft of the
basic security scenarios at
http://www.ws-i.org/Profiles/BasicSecurity/2004-02/SecurityScenarios-0.15-WGD.pdf
<raj>
Whichever we end up using,
I have couple of observations (a) using something from OGSA-WG might be
useful so that this document highlights the security, (b) certain scenarios
may highlight the usage of different domains/components (e.g., scheduling,
logging, etc) and there may not be one scenario that may fit to show an
end to end security usage in the context of the proposed architecture.
If someone (maybe from the "security design team" from OGSA WG)
can volunteer to draft a scenario out of OGSA-WG and extend it to
reflect the security architecture.. that would be good too.
In short, as long as a scenario
showcases the use of security components, it should be fine. I don't have
a particuluar opinion on which scenario to use.
</raj>
I think that last decision can await conclusion of the Model section,
but its development should
be informed by the efforts above.