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