OGSA teleconference January 29, 2004 ==================================== * Participants Bill Horn (IBM) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Takuya Mori (NEC) Andreas Savva (Fujitsu) Frank Siebenlist (ANL) David Snelling (Fujitsu) Jem Treadwell (HP) * Summary of actions ** [F2F preparation] Action: Hiro to check with Jeffrin whether the scheduled F2F UC discussion is ok. Action: Hiro/Dave to ask Dave Berry if he can lead the discussion on Data. Action: Hiro to confirm that Chris or Ming can lead the discussion on WS-Agreement. ** [Security discussion] Action: Takuya/Frank to work on a consistent definition of trust for the OGSA document. Action: Takuya to redo p5 to make transitions and actions clearer. Action: Takuya to redo figure on p9 to show the correct relationship. Action: Takuya to make "agreement" term usage clearer. Action: Takuya to rewrite p13 and remove ambiguity. Action: Takuya/Frank to clarify hierarchy concepts and also provide a more concrete use case for this feature. Action: Frank to re-think the need for a separate concept. Arrange to revisit this topic later. Action: Revise OGSA Ch.4 and also draw up list of services to go in Ch.6. Action: Takuya/Frank to check with Jeffrin if it is ok to add this use case to the use case document. Action: Takuya and Frank to get together and decide how to prepare for the F2F. * Early discussion ** Last call's minutes not available ** F2F proposed agenda - Power breakfast (aka WSRF discussion) Unfortunately Jay can't make the F2F. Instead Jeff Frey & Dave Snelling will lead discussion. (Dave is probably coming.) - Use cases - Jeffrin is currently on vacation. Not sure if the scheduled discussion is ok. Action: Hiro to check with Jeffrin whether the scheduled F2F UC discussion is ok. - Data - Neither Jay nor Ian will be attending. Proposed Dave Berry as a substitute as he is involved with DAIS-WG. Action: Hiro/Dave to ask Dave Berry if he can lead the discussion on Data. - PE - Suggestion to split this session up into smaller focused chunks (e.g., 20 minutes each) and assign more people (not just Andrew). Two obvious candidate areas to check alignment: - WS-Agreement: Choose someone who attended the recent GRAAP F2F. Maybe Chris Smith or Ming Xu. - JSDL: Andreas. - There are probably more candidate areas but it is not clear if there is a relevant GGF group. E.g., - How is actual job submission done - Job as manageable entity (WSDM probably) - CGS (JSIM) also came up. They are doing models not services but there is a connection. - CDDLM (e.g., what's the different between submitting a deployment request and a job?). CDDLM co-chair will be attending. Action: Hiro to confirm that Chris or Ming can lead the discussion on WS-Agreement. - Session (4-1) is platform services discussion. - producer/consumer discussion is intended as continuation of last Monday's (1/26) teleconference. - Session (4-2) deals with chapter 6 updates. There are probably not that many at the moment. ** Agenda bashing - Andreas has the pen at the moment. Contact him if you need the pen or the latest draft. * OGSA-WG Security Use Cases (Digital library use case) Ref: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/01/msg00047.html Intended as a simple security UC to highlighted needed OGSA security functionality. ** p3 (VO: Overview) What does "flexible authorization patterns" mean? (Takuya) Resource providers can enforce policies; some policies come from resource owners; some from users. (Hiro): Not clear what trust relationship means is in this presentation. ** p4 Why is trust management not listed? - Trust is actually stated in policy - WS-Trust exists but deals mainly with key exchange protocol; not trust. (Trust service in Fig 2 of OGSA document is something like a kerberos or xmkms service) Trust management on next page (p5) is different from key exchange. (Takuya) The term trust is probably used ambiguously in this document. Action: Takuya/Frank to work on a consistent definition of trust for the OGSA document. ** p5 (Lifecycle of VOs) (Hiro) This page talks about VO lifecycle. But what are the states and what are the (actions causing) state transitions? (It is not clear what trust & identity management mean here.) Action: Takuya to redo p5 to make transitions and actions clearer. (Frank) Maybe something like: Create VO -> Initialize Member Administrator role -> [VO is in a state that can accept members] -> Add members -> Initialize Resource Administrator role [VO is in a state that can be assigned resources] -> ... ** p9 (Step 1: School Participation) Policy statements probably exist on both sides. (The VO and each RO have their own policy but this aspect is not explored in detail in this presentation. Many kinds of policies may exist.) This figure: - RO establishes relationship with VO - VO (also) stands separately Hence figure is misleading. It would be more correct (but still not exactly right) to replace Library RO_L with Library VO. Action: Takuya to redo figure on p9 to show the correct relationship. .. Between p9 and p10 there is another step (identity management) .. ** p10 Content access management based on identity ** p11 Optional configuration that shows multiple VOs "agreement" here refers to a set of policies. (Does not (necessarily) mean WS-Agreement.) Action: Takuya to make "agreement" term usage clearer. ** p12 Shows that nested VOs are possible ** p13 (Contributing Local Library to Public) (Hiro): About statement 2: Does this mean a member can change central library contents that may not have originated with the member? (Takuya) Not the intention. The intention is to show that there is some benefit from participation in a VO. Action: Takuya to rewrite p13 and remove ambiguity. ** p16 (VO Security Services) - Each VO is expected to have a set of security services. - The services listed here are the ones Takuya thinks are needed by VOs. - VO hierarchy - Might have ISV that can host VOs. E.g., a library data center might offer a VO factory service (and hosting). Hence RO includes VO factory. - Including VO factory in VO may be a (shorthand) way of saying that a VO created there inherits some 'property/policy/resource/X' from the 'parent' VO. Action: Takuya/Frank to clarify hierarchy concepts and also provide a more concrete use case for this feature. ** p17 VO Manager is a role. ** p23 (Establishment of Trust Relationship) Lots of work needs to be done to fill in the gaps around trust. (Frank) Trust is defined by the administration policy statements - Someone is trusted because he was empowered to do something. - Someone is trusted because they are allowed to use some resources. In many ways trust management deals with empowering participants to do things. (Hiro) It may not be appropriate to talk about trust mgmt as a separate service. (Frank) Think of trust as anchor, i.e., trust root. (Dave: Certification authority and registration authority parallel) - Maybe trust is a functionality and not a service. - (Frank) Trust root management maybe a service. - What is the difference between trust root mgmt and identity mgmt? Isn't everyone a trust root of their identity? (So trust root management is identity mgmt + attributes.) Action: Frank to re-think the need for a separate concept. Arrange to revisit this topic later. ** How to proceed from this point Action: Revise OGSA Ch.4 and also draw up list of services to go in Ch.6. Action: Takuya/Frank to check with Jeffrin if it is ok to add this use case to the use case document. Action: Takuya and Frank to get together and decide how to prepare for the F2F.