[OGSA-AUTHZ] Revised Charter

Mon Apr 24 19:27:08 CDT 2006

David,

Thanks for the quick reply. Your response really helps me better understand the thinking behind the draft, though I still find parts of the document confusing as written.

It occurs to me the document might be clearer if structured into three sections.

1. Background discussion and definition of the WG scope. As you noted, this is still fuzzy and needs discussion and resolution. This would also be a good place to describe the basic architecture assumed going in and note its open to revision.

2. Initially chartered deliverables. This probably includes the scenarios and requirements doc; perhaps the architecture doc?; the two drafts you recently submitted; the VOMS doc discussed on the list today (not being involved in the development of these last 3, I don't have an opinion on their urgency). This would get rid of the confusing distinction of 'early' and 'initial' deliverables.

3. A discussion of the charter revision process for adding new deliverables. I'm assuming we'd want a a streamlined process for amending the charter with a new deliverable so long as it fits within the scope described in #1. The list of tentative deliverables could also go in this section.

Does this make sense? As should be evident, I'm in favor of a broadly scoped AuthZ WG charter that can accommodate multiple deliverables. Are there people who would prefer another approach?

Some other comments in-line

\Blair

> -----Original Message-----
> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]
> Sent: Saturday, April 22, 2006 10:17 AM
> To: Blair Dillaway
> Cc: ogsa Authz
> Subject: Re: [OGSA-AUTHZ] Revised Charter
>
> Hi Blair
>
> You are right that the charter is somewhat schizophrenic. I
> was aware of this when I was updating the previous charter.
> This is due to two competing (though I hope not necessarily
> conflicting) requirements.
>
> Firstly there is an urgent need to update the existing
> OGSA-Authz profile due to a number of well documented
> deficiencies that early practitioners soon discovered. This
> update is being driven by a number of current security
> related research projects that have deadlines and
> deliverables. In order to avoid them implementing home made
> proprietary solutions, a standard profile in a relatively
> short time scale is required. This accounts for the section
> of the charter dealing with PEP-PDP type interactions.
>
> Secondly there is the requirement to bring many more grid
> users on board and to discover what their pressing and wider
> authorisation requirements are. This accounts for the section
> of the charter devoted to requirements capture and charter revision.

Agreed. It's a reason the fuzzy scope concerns me. Its hard to get people to donate time to this sort of thing when its unclear what requirements needs to be documented.

>
> The reason that I dont believe that the two are conflicting,
> is that the concept of a PEP and a PDP are already well
> established (for more than 10 years) and unlikely to be
> disbanded in the short or medium term. Thus a PEP-PDP profile
> is unlikely to be thrown out of the revised charter.
> What I believe will happen (and this is a personal opinion
> now) is that the additional components such as STSs, PIPs,
> PAPs etc that are now mentioned in the literature will become
> widely accepted in due course and a single model for them all
> will become as widely accepted as the PEP-PDP model. I have
> made a start on this using the term credential validation
> service to unify the PIP and the STS-V, although I have no
> strong views about its title (you can call it a PIP or an
> STS-V if you want), it is the functionality that is important
> to the profile.

I don't think we disagree on the basic functional components, or the maturity of our understanding on how best to compose them. I was concerned about what seemed be architectural assumption implied by some of the doc titles: for example, that only a PEP interacts with a CVS.

>
> Blair Dillaway wrote:
> > David,
> >
> > I've reviewed the proposed charter and have a few concerns: (1) the
> > definition of what are considered in-scope authorization components
> > seems imprecise
>
> This is correct, intentionally so, and it will remain so
> until the revised charter is drawn up with more user involvement
>
> (2) the proposed two-phased approach, with an interim
> > charter revision, is in conflict with other statements in
> the charter
>
> Agreed, this is due to the schizophrenia mentioned above. I
> dont know how to resolve this one in the short term, but if
> you do then I would welcome your input.
>
>
> >  (3) an authorization architecture is presumed by the charter while
> > calling out an architectural specification as a deliverable
>
> A limited architecture is presumed now, comprising a PEP, PDP
> and call it a CVS for now, and this will be expanded as we
> get more input from others.
>
>
> >
> > Let me try to briefly describe what concerns me in each area.
> >
> > (1) The charter states the purpose is to define
> specifications needed
> > to support interoperability and pluggability of authorization
> > components. That is a reasonable objective,
>
> thankyou. We should keep this as uppermost in mind as the
> driving principle.
>
>
>   but the discussion that
> > follows seems to go beyond what would traditionally be considered
> > authorization. It seems to indicate that authentication (CVS
> > credential validation and trust assessment),  SAML authentication
> > token profiles; attribute schema communication, and some types of
> > security protocols are all in-scope. Its unclear to me if
> some aspects
> > of identity management systems and security policy
> > management/provisioning systems are also intended to be in-scope. I
> > suggest including a brief background section, which identifies the
> > major functional components needed in a complete Grid security
> > solution: identity management; policy management; secure
> > communications; authentication; authorization; audit (aka
> > accounting);.... I hope we could clearly indicate which of those
> > functional components are in-scope and which aren't.
>
> This is what I intended to happen. We do need a clear
> agreement on what is in scope and what isnt, and the revised
> charter should have a firm statement on this. In the current
> charter I put ideas which have been mentioned by various
> people into the pot so that they could be discussed more openly.
>
>
> >
> > (2) The charter states the initial deliverables of the group will
> > include a scenarios and requirements document along with a revised
> > charter based upon that work. That seems like a prudent approach to
> > ensuring the usefullness of standards ultimately developed by the
> > group. But, I can't reconcile that statement with the earlier
> > statement "an early deliverable of the group will be an enhanced
> > specification for the PEP-PDP interactions....".
> >
>
> Agreed, this is due to the schizophrenia mentioned above.
>
> > This, and the lengthy list of tentative documents, leaves
> me uncertain
> > if the OGSA-Authz charter is intended to be very broadly scoped,
> > allowing a number of different specifications to be
> developed, or to
> > charter work on individual specifications. If it's the former, I
> > suggest re-writing the charter to focus more on defining
> the overall
> > scope and addressing how the individual specfication
> activities will
> > be managed. The list of 'tentative documents' doesn't
> really belong in
> > such a charter. If it's the latter, perhaps this should be
> separated
> > into two more focused charters for the 'initial' and 'early'
> > deliverables identified in the current document.
>
> This is something that the group as a whole should decide.
>
> Personnally I dont see a conflict in aiming for the former,
> whilst leaving a tentative  best guess list of what the
> eventual specifications might contain. You could regard the
> list as a provisional shopping list for a recipe that hasnt
> been fully specified yet, but we have a general idea of the
> common ingredients.
>
> >
> > (3) It is stated "the group will also provide an architecture
> > document..." and later that one of the 'tentative documents' is a
> > 'high level authorization architecture'. I believe this is an
> > important document for focusing and relating the other
> specifications
> > mentioned in the charter. But, is this a chartered
> activity, or is it
> > dependent on the revised charter?
> >
>
> I hope it will be both ie. agreed to in the current charter
> and carried over into the revised one.
>
> > Its also stated the initial scenario and requirements work should
> > drive this document. At the same time, the charter clearly
> presumes an
> > authorization architecture for the various documents discussed.
> > For example, the PEP, PDP, and CVS separation. Some
> exisitng systems
> > conform to this architecture, others don't. The charter
> should clearly
> > state if the activities are constrained by this architecture or if
> > alternative architectures are in-scope.
>
> Personnally I would not want the architecture to be
> constrained at this point in time. There has been too little
> discussion yet to agree upon any final architecture.
>
> >
> > I also suggest the 'desired' document "Implementers of the Authz
> > infrastructures and the protocols specified by this group should
> > specify how their implementations map into the concepts
> documented in
> > the architecture document..." should be a requirement.
> Without this,
> > it can be very difficult to understand how individual
> specifications
> > relate and are expected to interface.
> >
>
> I happy to upgrade this to a requirement, but the reason it
> is desired, is that the group cannot mandate that any
> particular authorisation infratructure provider writes such a
> document. And it would be difficult for others to write it
> for them. So this is why it is desirable.

I apparently interpreted this incorrectly and thoughtit was referring to deliverables. Now that I understand it, I agree with your rationale.

>
>
> > ------
> >
> > On a related issue, could you clarify if the recent draft
> > specification submitted for comment (XACML profile and WS-TRUST/SAML
> > profile) are being proposed as deliverables under the
> OGSA-Authz WG or
> > some other WG?
>
> Under the OGSA-Authz WG
>
> regards
>
> David
>
> >
> > Regards, Blair Dillaway
> >
> >
> >> -----Original Message----- From: owner-ogsa-authz at ggf.org
> >> [mailto:owner-ogsa-authz at ggf.org] On Behalf Of David Chadwick Sent:
> >> Wednesday, April 19, 2006 3:39 AM To: ogsa Authz Subject:
> >> [OGSA-AUTHZ] Revised Charter
> >>
> >> Dear authz members
> >>
> >> please find attached an updated version of the charter for
> >> ratification at the next GGF meeting.
> >>
> >> If you have any comments on this charter please raise them on the
> >> list or at the next meeting in Tokyo, where I hope to get it
> >> ratified.
> >>
> >> Finally, can I ask for volunteers to start work on the
> authorisation
> >> scenarios and use cases document. There must be many of you on the
> >> list who already have great experience of implementing or
> integrating
> >> authorisation mechanisms into your grid applications and know the
> >> scenarios that you are working with, and the authorisation
> features
> >> that you require. So it should not be difficult for you to write
> >> these down on one or two sides of A4. I am happy to act as
> editor and
> >> to coordinate your input into the GGF output document.
> >>
> >> I look forward to seeing you in Tokyo
> >>
> >> regards
> >>
> >> David
> >>
> >> --
> >>
> >> *****************************************************************
> >> David W. Chadwick, BSc PhD Professor of Information
> Systems Security
> >> The Computing Laboratory, University of Kent, Canterbury,
> >> CT2 7NF Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77
> >> 96 44 7184 Email: D.W.Chadwick at kent.ac.uk Home Page:
> >> http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web
> >> site: http://sec.cs.kent.ac.uk Entrust key validation string:
> >> MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5
> >>
> >> *****************************************************************
> >>
> >>
> >
> >
> >
>
> --
>
> *****************************************************************
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security The Computing
> Laboratory, University of Kent, Canterbury, CT2 7NF
> Tel: +44 1227 82 3221
> Fax +44 1227 762 811
> Mobile: +44 77 96 44 7184
> Email: D.W.Chadwick at kent.ac.uk
> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
> Research Web site: http://sec.cs.kent.ac.uk Entrust key
> validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5
>
> *****************************************************************
>
>