======================================================================
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.