AuthZ WG Home Documents: Framework Glossary Requirements Archive: GGF8 Minutes GGF8 Agenda Telco 2003-06-03 Telco 2003-05-27 Telco 2003-05-20 GGF7 #1 - GGF7 #2 GGF7 Agenda Telco 2003-02-26 Telco 2003-02-19 Telco 2003-02-12 Telco 2003-02-07 BOF Agenda BOF Minutes BOF Handout Related Efforts Current users: guest (web) guest (web) guest (web) |
GGF Authorization Frameworks and Mechanisms Working GroupGGF7 Meeting 1, Wed Mar 5 2003 12:00-13:30Comet room, Hotel Intercontinental Keio Plaza, Tokyohttp://java.cs.vt.edu/public/users/mlorch/Grid-AuthZ/Home Slides are available at: http://zuni.cs.vt.edu/grid-authz/ggf7-2003-03-05-v3.pdf http://zuni.cs.vt.edu/grid-authz/ggf7-2003-03-05-authzreq-doc.pdf Agenda: 1. Introduction and overview of WG charter, scope + documents (15 min) 2. Review of timeline, milestones and goals (15 min) 3. Discussion of outline + content of requirements summary document (45 min) 4. Discussion of outline + content of glossary document document (15 min) Minutes (by Jim Basney and Dane Skow): Markus reviewed the GGF Intellectual Property Notice Markus reviewed the agenda. Dan Skow volunteered to take minutes. Markus reviewed the WG charter. Goal is the conceptual framework with terms for all expected actors, components and decision points. Looking to make 3 documents: a) Glossary b) Summary document of authorization requirements c) the conceptual framework document. c) is the major document. Draft is submitted to the GGF7 drafts area. Markus reviewed current status of the WG: - 28 people on mailing list - phone conferences held over last 3 weeks; minutes on web page Online drafts can be edited directly by anyone on the working group. We are not being formal about change tracking, though people should summarize their changes to the mailing list, please. Andrew presented plans for the requirements summary document: Inputs: Site AAA RG, ACE security, OGSA security, EU DataGrid Security Design, and others. Input from meeting attendees was solicited. Outputs: Collect pointers to descriptions of requirements and summarize. Will not put all requirements into one framework (checklist table). Comment: Target documents may have different definitions of authorization. Summary in this document will address which components of the target document apply. Request for volunteers of requirements. Questions/comments? Request for editor for this document. Matt Crawford is willing to be the editor if noone else steps forward. People are requested to submit pointers to requirement documents of which they are aware. This req document will be references to others whereever possible, but is looking to act as an index and top level summary, but not a replication of other work. Will not be a comprehensive checklist of all known requirements. The framework may have some of that character, but even then, the focus will be on the framework and how various requirements might be addressed, but again, just the frameworks, not the requirements themselves. Concern raised that this document should provide some "vetting" of the referred document and not just a list of URLs. Concern that there may be some mistakes or conflicting definitions that need to be resolved. Cees polled the room to see who is on the mailing list for this group and said he'd like to see more involvement. Markus reviewed the working group home page. Question: What is difference between author and editor? Editor pushes the document forward and brings the contributed pieces together. Markus gave an overview of the framework document. Major goal is for the framework document to establish the categorization criteria and interoperability points/limits for various authorization methods. There may or may not be recommendations about which method is most appropriate to different use cases. Aim: Introduce/define authorization models, define a conceptual grid authz framework as a basis for design, and categorize existing authz modules and systems. Outline: 1. Authz Framework concepts (entities, sequences/models) 2. Framework components 3. Existing authz mechanisms, modules, components, APIs Terms in current framework document draft: 1. Authorization Authority (AA) + AAH 2. Authorization Subject (AS) + ASH 3. Service Owner (SO) + SOH Comment: We should use IETF or ISO terms if possible. Will be effort to get the ISO documents to see whether or not the terminology can be reconciled with the IETF. A link to obtaining the ISO documents was sent to the mailing list last night. Claim was made that there is no barrier to sharing the ISO documents, and we are encouraged to refer to them. Comment: We don't want to clash in meaning with IETF or ISO terms. Sequences/Models: 1. Push: ASH gets authz from AAH and pushes it to SOH 2. Pull: ASH requests service from SOH, and SOH pulls authz from AAH 3. Agent: ASH sends request to AAH, and AAH bundles authz with request and sends to SOH Comment: May have an authz repository where authorizations are stored or cached so you don't always need to talk to AAH. For example, in pull sequence, SOH could have cached authz. AAH could issue authz into repository out-of-band, separate from being used. The sequence may not be completed all at the same time. They could be separated in time. Comment: Sequences/models can be combined. Alternative terms for the framework: Authorization Authority: Source of Authority (SOA) - X509, DNS Attribute Authority (subordinate to SOA) Stakeholder Authorization Subject: Initiator Service Owner: Target Access Control Info, Authorization Info, AuthZ Tokens, AuthZ Policy Comment: Acronyms can be difficult to read, i.e., SOA vs. Stakeholder. Comment: Stakeholder is more broad in general usage. Authorized users have a stake in it. Comment: Authorizor, authorizer? Comment: We should have a good reason for not using IETF terms. For example, User Home Organization (problematic). Different IETF groups use different terms. ADF, AEF. Comment: Authorization Source and Authorization Subject? Then refer to Source and Subject in the text. Comment: What does Authorization Source mean when you consider delegation? Comment: Why is ISO model as is not acceptable? Can we use the IETF or ISO terms? Leon: IETF terms are focused on networked environment. Want to step away from those terms to be more general. Comment: Could use X509 terms. In general is a bad idea to create a new set of terms. David Chadwick will provide a summary of the ISO terms on the mailing list to be discussed tomorrow. Since there was some time left in the session, Markus and Krishna reviewed the framework document outline and asked for comments. Comment: PEP and PDP should be included in the framework. Also where does policy fit? The framework needs to be richer with more compoments. Meeting adjourned. |
| /public/users/mlorch/Grid-AuthZ/GGF7 AuthZ1 Minutes | Login | Web Editor | Full Editor |
| Last modified 3/5/03 12:35 AM by mlorch (history) Site contents | |