Hi PGI team, looking at the latest conversations I see a demand to discuss how we can actually profile/specify the security plumbings basically agreed from the group so far (maybe aligned with information plumbings describing the security setup). Unfortunately, there will be no telcon on Friday this week due to eastern holidays, but next week as usual. However, we should start a discussion how we can specify the three plumbings for authN and two plumbings for authZ we agreed on so far. Addressing the comment from Steven around specifying the GSI elements: pro # MWSG means we could specify it although its not a real standard # A xyz PGI profile would support our production legacy systems contra # we have a PGI profile that includes already elements that are deprecated (GSI et al.) - plan was to just remove these plumbings over time... # it's harder to standardize instead of focusing on RFC elements However, from the most recent work in PGI I got the strong feeling that we have to stick to the three authN plumbings and two authZ plumbings - maybe people still disagree here, but I got a response from Alex Sim (SRM collaboration) mentioning that GSI is still all over the place and non-GSI versions (i.e. 3.0) will maybe deployed in the next 3-4 years... so out of scope of our work. The question arises how we specify these plumbings exactly. (1) Approach 1 (like WS-RF that consists of n specifications) # PGI data/job/security (our first document from the charter) ## PGI - AuthN - GSI ## PGI - AuthN - RFCProxy ## PGI - AuthN - EE ## PGI - AuthZ - SAML ## PGI - AuthZ - AC ## PGI - Data - ... Each of it would be a specification element part of the overall PGI standard. Adopters refer to it as specifying a server being PGI-AUTHN - RFCProxy Compliant, etc. (2) Approach 2 (similar like Duane's approach) We define everthing in one specification and combine our elements with # MANDATORY to support at least one of... # MANDATORY to support ...or / and # etc. Here adopters refer to Tags like PGI_COMM_XYZ within the PGI specification to indicate whether a system supports proxies or not. Any other approach I missed? Take care, Morris ------------------------------------------------------------ Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel "We work to better ourselves, and the rest of humanity" Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender)
------Original Message----- -From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of -Steven Newhouse -Sent: Wednesday, April 08, 2009 8:02 AM -To: Etienne Urbah; aleksandr.konstantinov@fys.uio.no; Duane MERRIL; pgi- -wg@ogf.org -Cc: edges-na3@mail.edges-grid.eu; lodygens@lal.in2p3.fr -Subject: Re: [Pgi-wg] OGF PGI - Security Model - NEW versions of GSI acceptRFC- -3820-compliant X509 proxies - -Etienne raises a valid point... - -> Important is that old versions of GSI, which do NOT accept RFC-3820- -> compliant X509 proxies, block interoperability, and are then STRONGLY -> DEPRECATED. - -These are still being used and supported (to provide legacy -compatibility) but alongside support for the newer X509 proxy system. - -> Therefore, each provider of grid middleware using such an old version -> of GSI : -> - MUST establish and publish the list of the components which still -> uses it, -> - SHOULD migrate to a new version of GSI which also accepts RFC-3820- -> compliant X509 proxies. - -This group has no right to mandate what middleware providers should or -should not do! But if no provider is JUST using old versions of GSI and -intend to migrate away from them I see no point in trying to define a -profile around something that has no clear specification (just the GT -implementation) and everyone intends to remove in the future. - -Surely its better to focus our energies on defining a profile around the -new style proxies that groups intend to support going forward? - -Steven - -_______________________________________________ -Pgi-wg mailing list -Pgi-wg@ogf.org -http://www.ogf.org/mailman/listinfo/pgi-wg