OGSA Teleconference - 11 August 2006 ==================================== * This is first half of Aug. 11 call * * Participants Andrew Grimshaw (UVa) Jay Unger (IBM) Frank Seibenlist (ANL) Steven Newhouse (OMII) Takuya Mori (NEC) Marvin Theimer (Microsoft) Jem Treadwell (HP) Duane Merrill (UVa) David Chadwick (U of Kent) Andreas Savva (Fujitsu) Donal Fellows (Uom) Minutes: Takuya Mori * OGSA authorization call-out proposal review (Frank, 20 min) Reference: "Functional Components of Grid Service Provider Authorisation Service Middleware" https://forge.gridforum.org/sf/go/doc13724?nav=1 David presented a draft document, "Functional Components of Grid Service Provider Authorisation Service Middleware", which was sent to the OGSA-AuthZ and OGSA-WG list on Aug 9. (The document was based on discussions between Von, Frank and David.) David introduced functional components, Policy Enforcement Point (PEP), Credential Validation Service (CVS) and PDP (Policy Decision Point) and showed four types of interactions between the components (See Fig.1 to Fig.4 in the document). David proposed to define two protocols, one for CVS and the other for PDP. The followings are the points of his proposal. - CVS is used to validate credentials and to issue valid attributes of Access Requestors. - CVS is passed authenticated name and credentials. - CVS determines if the credential is trust worthy and returns valid attributes. - An administrator manages two types of rules, auhtz decision rules and rules to resolve trust relationships - CVS makes use of XACML policy query interface, but it is not necessarily be an XACML policy engine behind the interface. - CVS is needed to separate authentication and authorization. Various questions and answers arouse during the presentation and some major points made clear in the discussion were: - The two protocols are intended to support all the configuration shown in the figures - Revisions of the two "OGSI" profiles are also in the scope of current activities of the OGSA-AuthZ-WG. - Defining attributes values (terms and semantics) is not in the scope of current activities of the OGSA-AuthZ-WG, but in its future scope. The discussion were suspended until Aug 28 due to the running out of the meeting time. The followings are some interactions during the discussion. * The scope of the work (1) Q: Does the two protocols cover all the configurations shown in the figures? The protocols shown in the figures look different. A: Yes, the both protocols can cover all the configuration. The current OGSA-Authz profiles can handle this kind of interactions. Q: The current profiles are not "OGSA" profiles. These are "OGSI" profiles. A: The difference between "OGSI" and "OGSA" is small for OGSA-Authz profiles. Revisions of these two profiles are also on the table. * How to define service I/F of applications Q: As an application desginer, do I need to choose appropriate one? * long interactions were taken place which Takuya couldn't perfectly follow, but if Takuya understood well, the answer from the authz wg is: * A: Interafces of applications will not be affected. It is the middleware which speaks the protocols. Authorization is taken place behind the infrastructure. * The scope of the work (2) Q: The architecture for authorization has not clearly been defined. What the OGSA-AuthZ-WG are going to define? Do we need to define all the comopnents? Various terms and semantics also needs to be defined for attributes and policies. These also should be standardized. A: The OGSA-AuthZ-WG did the similar things in the past, the credential formats and terms over the SAML Attribute Assertion and the X.509 Attribute Certs. Q: It covers a different interop level - only attribute name or type level - not the values. A: The OGSA-AuthZ-WG focuses only on the interface level. David doesn't have a need to define values. (at this moment?) The WG needs to define them later in the future. -- Hiro Kishimoto