[acs-wg] Draft writing for GGF15

[Michael Behrens]

Thanks.
Also - I see there an action for me to drill down into Byte-IO.  I did 
talk with Mark Morgan about this at the OGSA meeting a little.  There 
specification can support extensions for other transport mechanism.  
I'll look over my notes and see if I can get some more details. 
Perhaps we can invite Mark to join our teleconference for a Q&A?

Keisuke Fukui wrote:

> Folks,
>
> FYI, attached is the minutes for telecon when we discussed about the
> security description in the past call.
>
> -Keisuke
>
> ------------------------------------------------------------------------
>
> Subject:
> [acs-wg] Teleconference minutes - June 15
> From:
> Sachiko Wada <sachiko at ascade.co.jp>
> Date:
> Mon, 15 Aug 2005 13:37:40 +0900
> To:
> acs-wg at ggf.org
>
> To:
> acs-wg at ggf.org
>
>
>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.
>  
>

-- 
Michael Behrens
R2AD, LLC
(571) 594-3008 (cell) *new*
(703) 714-0442 (land)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/acs-wg/attachments/20050901/f40786b6/attachment.htm