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@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
charter revision, is in conflict with other statements in
(2) the proposed two-phased approach, with an interim 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@ggf.org [mailto:owner-ogsa-authz@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@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@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
*****************************************************************