GGF9 Authorization Frameworks and Mechanisms (AuthZ-WG) Meeting Mon Oct 6 2003 14:00-15:30 Agenda: Administrative Brief Review Framework Document Glossary Document Meeting Summary: We reviewed changes in the framework document since GGF8 and discussed the terminology used in the document to improve consistency and clarity. The group decided that the framework dcoument content was complete and ready for submission to the editor as a GFD-I before GGF10, after one final round of edits focused mainly on terminology. We decided to keep the glossary document separate from the framework document. Work will continue on the glossary document, and it will be discussed again at GGF-10. Minutes: Markus reviewed the Agenda and noted the GGF IP Policy. The group's gridforge homepage is . Markus reviewed the history and current status of the WG. Framework document changes since GGF8: - section 5&6, providing a classification/overview of existing authz systems - delete old appendix (collection of data on various authz mechanisms) - added new appendix on domain authz models (complementing "Domain Considerations" section) - changes to policy section (deleted references to OGSI, etc.) - editorial changes Section 5 (Akenti, Cardea, CAS, PRIMA, PERMIS) Section 6 (SAML, XACML, XRML, WS-Security, ISO-10181-3) What needs to be done in Framework Document: - determine if content is "complete" now, do we have the right material? - addressing comments made on the list since ggf9 deadline (Dane & Von) - improve cohesiveness, style and wording of document - last call (before GGF10) - submission to editor as GFD-I Comment: Figure 2.3 is not consistent with terminology Split Authorization Agent into AuthZ Authority + Agent? No AuthZ Authority in the figure. Should have one. Will be changed before submission to GGF editor. Other comments? Anything missing? No. Glossary document: - Dane wrote it. - Dane asked question if glossary should be separate or added into framework document. - Some terms defined specific to framework document (policy == access policy) - Some definitions are long. Glossary should have short definitions. - Markus's reasons for keeping it separate - keep size of framework acceptable - see it as a more general glossary for authz in general (also the OGSA authZ documents currently being created) - if left separate we could also easier append and revise to it (keep this an up-to-date glossary) Dane proposed keeping definitions short, with references to source documents (including framework document). Glossary should contain general terms. If specific to a document, the term should be defined in the source document. Dane pleaded for section authors to review glossary for redundant terms. Is there a model in the framework document that the glossary terms are relative to? For example, federation is a term used differently by different groups. The framework document is abstract so terms should be general. How can framework document's abstractions be applied to virtual organizations and federations? Not all descriptions in section 4 are organized the same. Can they be re-organized (according to a template) or is it not worth the effort? Someone not familiar with the systems (without preconceived ideas) could rewrite all the sections for consistently. Could get authors to address the same concerns in the different sections. Focus each description on what is unique about each system. Will make an effort to unify the descriptions during the next editing pass on the document. Markus led a discussion on Dane and Von's questions on the list. Document is non-normative and attempts to capture best practice. AuthZ can mean: 1. The process of issuing a proof of right 2. The proof of right (or reference to it) itself (an authz token) 3. The process of checking a proof of right that is intended to grant that right (which yields an authorization decision). The framework document uses AuthZ mainly in the 3rd sense. Best approach may be to map terms to each of these. 1. issue authz 2. authz token 3. authz decision Will go through document to replace authz with clarified terms. Is right equal to a privilege? We use them equally in the document. General consensus they are equal. Add definition for domain: scope of authority. AuthZ Architecture vs. AuthZ System? System is an instance/implementation of an architecture. Also Framework, Architecture, and Model are used. In section 2.6, there was too detailed reference to OGSI. It's now cut down to a one paragraph description. Context vs. environmental factors: Context is info present in the request. Environmental factors refers to info known to the target a priori. XACML has environmental attribute. Distinction between these terms needs to be made more clearly. ISO-10181-3 has "access control decision information". Also, info retained from previous authz decision can be used for current authz decision. Agreement to use more specific terms in place of context. Does framework document contain all we want? Hum vote yes. Glossary as separate document? Yes. Timeframe? Framework document submitted before next GGF. Discussion glossary at next GGF.