Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050810/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 10 August 2005 ==================================== * Participants Pete Ziu (Northrop Grumman) Von Welch (ANL) Jay Unger (IBM) Jem Treadwell (HP) Mary Thompson (LBL) Ellen Stokes (IBM) Andreas Savva (Fujitsu) Takuya Mori (NEC) Mark Morgan (UVa) Tom Maguire (IBM) Fred Maciel (Hitachi) Hiro Kishimoto (Fujitsu) Andrew Grimshaw (UVa) Minutes: Andreas Savva * Minutes Aug. 8 approval postponed * WSRF Basic Profile 1.0 status update - The document is still in GGF Editor review. - Andrew as the Architecture (AD) will ask Greg Newby to bring it to GFSG review. * OGSA-AuthZ-WG discussion Introduction of OGSA-AuthZ-WG deliverables and preliminary discussion about next week's F2F. ** Authorization service document This document is still being revised. It is based on the SAML 1.1 model. A client makes an authorization request and gets back a response - Reply is one of "yes/no/indeterminate or not applicable" - If 'no', does it also return why not? No. - A 'yes' may still change to 'no' later due to other state changes - It actually returns an assertion containing information on what the client can do---the assertion is signed and has a validity period. - There is another variant where a client accesses a service and the service checks whether the operation is allowed at that time. - Is parameter based authorization supported? - Not in version 1 of the document but thinking about it for version 2. - Is it method level or message level? - It is 'method' level---on invocation. The document is basically a - SAML authorization assertion profile; and - extensions to address certain use cases - Does it depend on the OGSA WSRF BP or any other infrastructure? - Initially it was based on OGSI and then moved to WSRF - The document does talk about what state is exposed but does not use these features heavily; it is not a major dependency. - Is it a dependency or composition? In other words, is a service defined or just a set of abstract portTypes that can be composed with other portTypes? - At the moment OGSA-AuthZ is looking at this more as a standalone service. - But there is nothing stopping anyone from mixing the defined portTypes in their service. But conceptually that is not the model the OGSA-AuthZ group has been working with. - Suppose a client wants to access an endpoint. If the authorization point is separate from the service, how can the client find out where it needs to go to receive authorization? - It is out of scope. - A common pattern is to try and access the service endpoint and then the service goes and asks (its authorization point) if it is ok. - Otherwise the client has to be configured with a priori information. (And this also looks like a common case.) ** Attributes document It has been submitted to GGF and is now in public comment. - The Service document (above) came first. It ended up covering a large area so the Attributes portion was pulled out and made into this separate document. The Attributes document defines the - format of attributes and semantics; and - two profiles: SAML and x.509 - Hiro during an earlier review had suggested that this document should be re-formated as a profile document - It is true that some sections are profiles; while others are informational - Now thinking how to re-structure the document - Tom volunteered to help/give feedback with structuring this document as a Profile. These 2 documents are a pair and should really move through the process together but the Attributes document is ahead. In some ways the Attributes document is an addition/appendix of the Service document. ** Security session at F2F The plan is to continue further discussion of these two documents. Also the OGSA-Data WG has questions on the authorization service. There has been some email exchange but they also want to talk at the F2F. Finally how to structure the collaboration around OGSA security and how to start working together. Von is the current chair but he is in the process of handing over the group. Also the group is in process of re-chartering. There are a number of ideas for future work including updating the specifications to use SAML 2.0, integrating XACML work, etc. Hiro mentioned the OGSA naming rule that GFSG has been defining. A new charter for OGSA-AuthZ should include a statement that the group will collaborate with OGSA-WG as needed. - Hiro will send information to Von about this requirement. * Roadmap 1.0 review Review of revision to address public comments. - Sec 1.0: "...human resources..." statement revised. And re-revised to remove "...limited number of people..." - Sec 2.0: "...specifications and profiles..." revision. - "...recommended profile..." addition to define what this term means. Agreed not to duplicate detailed definitions from other documents but provide a short definition and reference. - GFD-I reference - Added Takuya's text describing the OGSA-AuthZ documents. (Needs review) - Table update - Waiting for an update for the Information document from Abdeslem - Discussed deadline to return the document to Greg - Since the F2F is next week it will probably take until the beginning of September. * F2F update - OGSA-EGA meeting - The EGA members have asked for this meeting to be a closed one. It was in the F2F agenda earlier so the implication was that it was a regular open session. For this reason Hiro has dropped it from the last agenda he posted. - A number of concerns were raised with having this as a closed session. - Only a limited number of people can attend (expected to be about 4). At the moment it is probably the two Chairs, Secretary and AD. - Fred also expressed an interest in taking part in this meeting. - It was agreed to discuss who will take part on Monday. - Hiro is still waiting for all the agendas to come in. He has added some new items for Thursday afternoon and Friday morning; including a discussion on re-chartering. - Friday is now scheduled 8-11am and 11am is a hard stop. * Architecture & Glossary 1.5 discussion Andreas confirmed that Andrew will be in charge of the EMS section revision. The EMS revision will cover the new work on BES, RSS, etc. Also the terminology problems raised during the last public comment should be fixed.