[OGSA-AUTHZ] Revised Charter
David Chadwick
d.w.chadwick at kent.ac.uk
Sat Apr 22 12:16:48 CDT 2006
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 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
*****************************************************************
More information about the ogsa-authz-wg
mailing list