[acs-wg] Teleconference minutes - June 15
Sachiko Wada
sachiko at ascade.co.jp
Sun Aug 14 23:37:40 CDT 2005
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
-------------- next part --------------
======================================================================
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.
More information about the acs-wg
mailing list