Hi team, Here is the minutes of the last teleconf. Please review it and point out where the record is not correct, if any. It is also available at Gridforge: https://forge.gridforum.org/projects/acs-wg/document/minutes-20050810/en/1 Sachiko ====================================================================== ACS Teleconference ----------------------------------------------------------------------- Date and Time: August 10 20:10-21:40 EDT 2005 / August 11 9:10-10:40 JST, 2005 Participants: Keisuke Fukui (Fujitsu) Tom Studwell (IBM) Peter Ziu (Northrop) Michael Behrens (R2AD) Sachiko Wada (ASCADE) - minutes ------------------------------------------------------------------------ * Review of the minutes of day 2 for F2F Minutes approved. * Data replication use case We glanced over the replication use case of OGSA-D. It seems that there are no conflicts between OGSA-D and ACS. We should learn data area specs, including another relevant WG such as ByteIO, so that ACS can get along with those specs. We continue this discussion on the ml. * Security updates We agreed on the basic security policy of ACS as Keisuke summarized in the previous post on Aug 10 JST. ------------------------------------------------------------------- - We may simply specify to reserve an extension point for access constraint information, such as XACML, in AAD. Optionally, we may describe our considerations as an informational part demonstrating how this can be utilized. - We will not specify the security features for ARI (SOAP message exchange) since this should be covered by existing standard spec or profile. We will refer to the external relevant specs or profiles, such as OGSA Basic Profile. - We may include description about the *optional* AA signature, in consideration mainly for when AA Document is handled out of secured path. Though we may define the range of contents that the signature will cover, the technologies to be used for signature, such as an XML signature or signature used in Jar file, may be left unspecified or just listed as candidates. - Authentication detail is up to the security entity in the system, both for specification and for design. The implementation of ACS may have interface to it, but the ACS specification will not specify it. (example interaction may be demonstrated as an informational description.) - ACS implementation can be one of the security PEP in the system, in a sense it may accept or reject the service request to the repository, depending on the Authorization Decision Assertion returned from the Policy Decision Point, which I assume the security entity (or service) in the system is. ACS may simply match the security token presented in the request (in a SOAP header part) and the Assertion, in order to enforce the policy. ------------------------------------------------------------------- Mike mentioned that ByteIO covers security issues in moving around files and we may find an input from it. Action: Mike, to look down into the ByteIO. * Meta data discussion The proposal from Keisuke and Sachiko is to sort out meta data for AA into two classes. It includes the below information for each: a) Static description for the AA, for example, - File list of the Application Contents with key information for GetContents. (REQUIRED) - AA Identifier, which contains name of the AA and version information. (REQUIRED) - Access control policy for each Application Content. (OPTIONAL) (Can be a pointer to actual file in ACs.) - Human-readable description of the AA (OPTIONAL) - Extension point, i.e. xsd:any (OPTIONAL) b) Live meta data that can be dynamically augmented by ACS repository. - Owner of the the AA instance (OPTIONAL ? ) This may be retrieved from the security token in the SOAP header or Create parameter (administrative information) in case of this process is done by the proxy service. - Creation datetime of the AA instance (REQUIRED) - Change history information for the AA instance. The static description may be augmented by ACS in the resource property of the AA instance. It may depend on what it is for. We continue this discussion on the ml. * Schedule for drafting a specification We agreed on the proposed TOC with some modification and made assignment of some of the sections. The proposed schedule is an aggressive one and we may need adjustment depending on the progress. Action: Keisuke, to post the latest TOC with the name in charge on the ml. (Done on Aug 11 JST) * Updates (NAREG PSE) Keisuke posted NAREGI PSE diagram on Aug 3 JST, which confirms that there is not issues between our spec. and their design. No issues or questions were raised. * Wrap up, Next meeting We agreed that we will skip the call for next week. Date: Aug 24 Wed 20:00 EDT/Aug 25 Thu 9:00 JST Calling #: will be announced later NOTE: Next regular meeting will be skipped.