October 2007 - ogsa-wg - lists.ogf.org

RSS Specification Submitted to Editor
by Donal K. Fellows 17 Oct '07

17 Oct '07

The RSS Specification has now been submitted to the Editor. Many thanks to the contributions of everyone who has commented, and especially to Andreas Savva. Donal.

1 0

Re: [ogsa-wg] OGSA-WG activities on the Express Profile
by Hiro Kishimoto 17 Oct '07

17 Oct '07

Hi Duane, Minor procedural comment. > As for the status of the OGSA-SP within the OGF document process, the > OGSA-SP is on schedule to enter public comment within the week. I would say the OGSA-SP is on schedule to make WG final call in this week and submit to the OGF editor for public comments in the following week. Thanks, ---- Hiro Kishimoto -------- Original Message -------- Subject: Re:OGSA-WG activities on the Express Profile From: Duane Merrill III <dgm4d(a)virginia.edu> To: Alan Sill <Alan.Sill(a)ttu.edu>, Andrew Grimshaw <grimshaw(a)virginia.edu> Cc: "Alan Sill" <Alan.Sill(a)ttu.edu>, "Shannon Hastings" <hastings(a)BMI.OSU.EDU>, "Hiro Kishimoto" <hiro.kishimoto(a)jp.fujitsu.com> Date: 2007/10/17 6:39 > Shannon and Alan, > > It sounds as if the caGrid /getServiceSecurityMetadata/() operation has > similar intent as the OGSA Security Profile (OGSA-SP, a.k.a., "Express > Profile") documents: to advertise and facilitate interoperable, secure > communication (or to cleanly determine if interoperability is not > possible). > > The mechanism for discovery is quite different, however. In part, the > OGSA-SP documents are profiles on WS-Addressing: how to convey > secure-communication requirements within endpoint references (EPRs). If > we were to apply the OGSA-SP to your use-case below, the EPR used by a > client to interact with a resource would indicate that the endpoint > requires a TLS transport layer (possibly also indicating a requirement > for mutual-authentication at the TLS layer). > > Why do this within the EPR? The EPR datastructure plays a crucial role > for addressing resources in the OGSA architecture and is extensively > incorporated into many of its service interfaces (e.g., notification, > execution management, directory services, resource management, etc.). > The utility of the grid derives from the dynamic composition of > services, and EPRs are how services refer to and address each other. > They encapsulate the "invocation context" for a resource: everything one > needs to know to communicate with it. Publishing security requirements > elsewhere (e.g., within WSDL, or exposed through reflective service > operations) incurs extra communication cost, availability and > interoperability risks, etc. > > How are communication requirements expressed? The OGSA-SP documents use > the newly ratified OASIS WS-SecurityPolicy standard to convey > secure-communication requirements. Although resources are free to > express arbitrary security requirements, the OGSA-SP documents define > well-known, composable security policies for common security > mechanisms. (And are perfectly extensible as new mechanisms are > introduced.) For example, the OGSA-SP presently contains composable > policies for server-authenticated TLS, mutually-authenticated TLS, > UsernameToken authentication, mutual-X.509 authentication, digital > signature and encryption of document elements, etc., most of which defer > completely to sections of the WS-I Basic Security Profile. In this > fashion, the OGSA-SP also serves as a location for minor mechanism > clarifications and refinements as Web services security mechanisms are > adapted to the Grid environment. > > As for the status of the OGSA-SP within the OGF document process, the > OGSA-SP is on schedule to enter public comment within the week. The > latest drafts of the OGSA-SP documents (and a potentially-languishing > use-case document) can be found at: > > https://forge.gridforum.org/sf/docman/do/listDocuments/projects.ogsa-wg/doc… > > The OGSA-SP documents themselves are architected in a hierarchical, > extensible fashion. The /OGSA-BSP Secure Addressing/ document defines > the general attachment mechanism for conveying security policy within > EPRs as well as how to make them tamper-resistant through digital > signature. The /OGSA-SP Secure Transport/ document defines well-known > policies for de-facto transport-level secure communication > configurations. The /OGSA-SP Secure SOAP Messaging/ document defines > analogous policies for de-facto message-level security mechanisms. > > If you have someone at OGF and are interested in more detail, I will be > presenting the OGSA-SP documents at the > /OGSA Express Authentication Security Profile/ session on Thursday > afternoon, 3:15 pm - 4:45 pm, and would enjoy discussing them further. > > Cheers, > > Duane > > > > > ----- Original Message ----- > From: "Alan Sill" <Alan.Sill(a)ttu.edu <mailto:Alan.Sill@ttu.edu>> > To: "Duane Merrill" <dgm4d(a)virginia.edu <mailto:dgm4d@virginia.edu>>; > "Andrew Grimshaw" <grimshaw(a)virginia.edu <mailto:grimshaw@virginia.edu>> > Cc: "Alan Sill" <Alan.Sill(a)ttu.edu <mailto:Alan.Sill@ttu.edu>>; "Shannon > Hastings" <hastings(a)BMI.OSU.EDU <mailto:hastings@BMI.OSU.EDU>>; "Hiro > Kishimoto" <hiro.kishimoto(a)jp.fujitsu.com > <mailto:hiro.kishimoto@jp.fujitsu.com>> > Sent: Tuesday, October 16, 2007 2:36 PM > Subject: OGSA-WG activities on the Express Profile > > > Duane and Andrew, > > > > Can you catch us up, including Shannon, on the activities with > > respect to the Express Profile and related documents, as they might > > relate to the use case described below? Shannon works with the > > CaGrid group, and says that they have someone out at OGF who might be > > able to interact with you about this if you are there. Meanwhile, a > > few web links and a status update as regards the use case documents > > and draft profile might be useful. > > > > Thanks, > > Alan > > > > Begin forwarded message: > > > >> From: Shannon Hastings <hastings(a)BMI.OSU.EDU > <mailto:hastings@BMI.OSU.EDU>> > >> Date: October 16, 2007 12:43:22 PM CDT > >> To: CAGRID_USERS-L(a)LIST.NIH.GOV <mailto:CAGRID_USERS-L@LIST.NIH.GOV> > >> Subject: Re: operations added by Introduce > >> Reply-To: caGrid Users discussion Forum <CAGRID_USERS-L(a)LIST.NIH.GOV > <mailto:CAGRID_USERS-L@LIST.NIH.GOV>> > >> > >> Please do. We have recently become aware of another similar effort > >> within the grouper group. Maybe this is the same effort. Steve is > >> out > >> at OGF this week so when he gets this email he can try to find those > >> folks as well. > >> > >> Thanks, > >> Shannon > >> > >> > >> Shannon Hastings > >> co-Director > >> Software Research Institute > >> Department of Biomedical Informatics > >> Ohio State University > >> > >> Office: (614) 292-9461 > >> Lab: (614) 292-9845 > >> hastings(a)bmi.osu.edu <mailto:hastings@bmi.osu.edu> > >> > >> > >> -----Original Message----- > >> From: caGrid Users discussion Forum [mailto:CAGRID_USERS- > >> L(a)LIST.NIH.GOV <mailto:L@LIST.NIH.GOV>] > >> On Behalf Of Alan Sill > >> Sent: Tuesday, October 16, 2007 12:27 PM > >> To: CAGRID_USERS-L(a)LIST.NIH.GOV <mailto:CAGRID_USERS-L@LIST.NIH.GOV> > >> Subject: Re: operations added by Introduce > >> > >> FYI, there is now an effort to define an architecture for > >> specification, advertising and discovery of security requirements of > >> exactly this nature in the context of the OGSA-WG "Express Profile" > >> as a profile under WS-Security. If you are interested in this work, > >> I would be happy to put you in touch with members of that group so > >> you can read the profiles and use cases, and comment. > >> > >> Thanks, > >> Alan > >> > >> On Oct 16, 2007, at 10:48 AM, Shannon Hastings wrote: > >> > >>> To be even more specific just in case you are concerned about > >>> security. > >>> > >>> getServiceSecurityMetadata is an operation that is always public on a > >>> service. What it does is tell any client what it required to talk to > >>> the service. It contains no more information than that. It > >>> enables a > >>> client to know that he cannot talk to the service without a using TLS > >>> for example. > >>> > >>> The other three methods are part of the wsrf spec regarding resource > >>> property access. These methods will use whatever security setting > >>> you > >>> put on your service. If you say that your service is secure and set > >>> authorization requirements at he service level in introduce, than > >>> these > >>> methods will also inherit this security. So you have total > >>> control of > >>> whether your resource properties are available. Now keep in mind, > >>> there > >>> are resource properties of the service, not the service properties > >>> (which should be used for internal configuration and are not > >>> available > >>> through any operations). > >>> > >>> > >>> > >>> Shannon Hastings > >>> co-Director > >>> Software Research Institute > >>> Department of Biomedical Informatics > >>> Ohio State University > >>> > >>> Office: (614) 292-9461 > >>> Lab: (614) 292-9845 > >>> hastings(a)bmi.osu.edu <mailto:hastings@bmi.osu.edu> > >>> > >>> > >>> -----Original Message----- > >>> From: caGrid Users discussion Forum [mailto:CAGRID_USERS- > >>> L(a)LIST.NIH.GOV <mailto:L@LIST.NIH.GOV>] > >>> On Behalf Of Shannon Hastings > >>> Sent: Tuesday, October 16, 2007 11:41 AM > >>> To: CAGRID_USERS-L(a)LIST.NIH.GOV <mailto:CAGRID_USERS-L@LIST.NIH.GOV> > >>> Subject: Re: operations added by Introduce > >>> > >>> These are required operations of any caGrid service. They are > >>> provide > >>> access to querying the resource properties of the main service as > >>> well > >>> as the security configuration of the service. This security > >>> information > >>> is just metadata about the requirements needed to connect to the > >>> service. This enables a client to know that it will need a > >>> certificate, > >>> or will need to use SSL. You should not disable these operations. > >>> For > >>> more information on them. The resource property ones are related > >>> to the > >>> WS specifications and the getSecurityMetadata is a caGrid only > >>> operation > >>> which you can read about at caGrid.org in the Introduce technical > >>> guide. > >>> > >>> Shannon > >>> > >>> > >>> Shannon Hastings > >>> co-Director > >>> Software Research Institute > >>> Department of Biomedical Informatics > >>> Ohio State University > >>> > >>> Office: (614) 292-9461 > >>> Lab: (614) 292-9845 > >>> hastings(a)bmi.osu.edu <mailto:hastings@bmi.osu.edu> > >>> > >>> > >>> -----Original Message----- > >>> From: caGrid Users discussion Forum [mailto:CAGRID_USERS- > >>> L(a)LIST.NIH.GOV <mailto:L@LIST.NIH.GOV>] > >>> On Behalf Of Joel Schneider > >>> Sent: Tuesday, October 16, 2007 11:27 AM > >>> To: CAGRID_USERS-L(a)LIST.NIH.GOV <mailto:CAGRID_USERS-L@LIST.NIH.GOV> > >>> Subject: operations added by Introduce > >>> > >>> I noticed that a service created using Introduce has the following > >>> four operations, in addition to the operations I defined by hand: > >>> > >>> getResourceProperty > >>> getMultipleResourceProperties > >>> queryResourceProperties > >>> getServiceSecurityMetadata > >>> > >>> This service in question was originally created using Introduce > >>> 1.0 as > >>> an analytical service, and later migrated to Introduce 1.1. > >>> > >>> The presence of these additional operations raises a number of > >>> questions. > >>> > >>> 1) What is the purpose of the additional operations? > >>> > >>> 2) If these operations are not required by my service, is there an > >>> easy > >>> or recommended way to remove or disable them? > >>> > >>> 3) From a security perspective, I'm concerned these operations might > >>> expose the service's ServiceConfiguration to a remote user. Is > >>> that > >>> the case? (Where is the code which implements these operations?) > >>> > >>> Help with these questions would be much appreciated. > >>> > >>> Best regards, > >>> Joel > >>> > >>> -- > >>> Joel Schneider National Marrow Donor Program > >>> Software Developer (Contractor) 3001 Broadway Street NE > >>> phone: 612-617-8321 Minneapolis, MN 55413 > >>> email: jschneid(a)nmdp.org <mailto:jschneid@nmdp.org> > http://www.marrow.org/ > > > > Alan Sill, Ph.D > > TIGRE Senior Scientist, High Performance Computing Center > > Adjunct Professor of Physics > > TTU > > > > ==================================================================== > > : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : > > : e-mail: Alan.Sill(a)ttu.edu <mailto:Alan.Sill@ttu.edu> ph. > 806-742-4350 fax 806-742-4358 : > > ==================================================================== > >

1 0

Re: [ogsa-wg] OGSA-WG activities on the Express Profile
by Andrew Grimshaw 17 Oct '07

17 Oct '07

Guys, Please have the discussion on the OGSA-wg mailing list so everyone can see _____ From: Duane Merrill III [mailto:dgm4d@virginia.edu] Sent: Tuesday, October 16, 2007 5:40 PM To: Alan Sill; Andrew Grimshaw Cc: Alan Sill; Shannon Hastings; Hiro Kishimoto Subject: Re: OGSA-WG activities on the Express Profile Shannon and Alan, It sounds as if the caGrid getServiceSecurityMetadata() operation has similar intent as the OGSA Security Profile (OGSA-SP, a.k.a., "Express Profile") documents: to advertise and facilitate interoperable, secure communication (or to cleanly determine if interoperability is not possible). The mechanism for discovery is quite different, however. In part, the OGSA-SP documents are profiles on WS-Addressing: how to convey secure-communication requirements within endpoint references (EPRs). If we were to apply the OGSA-SP to your use-case below, the EPR used by a client to interact with a resource would indicate that the endpoint requires a TLS transport layer (possibly also indicating a requirement for mutual-authentication at the TLS layer). Why do this within the EPR? The EPR datastructure plays a crucial role for addressing resources in the OGSA architecture and is extensively incorporated into many of its service interfaces (e.g., notification, execution management, directory services, resource management, etc.). The utility of the grid derives from the dynamic composition of services, and EPRs are how services refer to and address each other. They encapsulate the "invocation context" for a resource: everything one needs to know to communicate with it. Publishing security requirements elsewhere (e.g., within WSDL, or exposed through reflective service operations) incurs extra communication cost, availability and interoperability risks, etc. How are communication requirements expressed? The OGSA-SP documents use the newly ratified OASIS WS-SecurityPolicy standard to convey secure-communication requirements. Although resources are free to express arbitrary security requirements, the OGSA-SP documents define well-known, composable security policies for common security mechanisms. (And are perfectly extensible as new mechanisms are introduced.) For example, the OGSA-SP presently contains composable policies for server-authenticated TLS, mutually-authenticated TLS, UsernameToken authentication, mutual-X.509 authentication, digital signature and encryption of document elements, etc., most of which defer completely to sections of the WS-I Basic Security Profile. In this fashion, the OGSA-SP also serves as a location for minor mechanism clarifications and refinements as Web services security mechanisms are adapted to the Grid environment. As for the status of the OGSA-SP within the OGF document process, the OGSA-SP is on schedule to enter public comment within the week. The latest drafts of the OGSA-SP documents (and a potentially-languishing use-case document) can be found at: https://forge.gridforum.org/sf/docman/do/listDocuments/projects.ogsa-wg/docm an.root.working_drafts.security_profiles_use_case The OGSA-SP documents themselves are architected in a hierarchical, extensible fashion. The OGSA-BSP Secure Addressing document defines the general attachment mechanism for conveying security policy within EPRs as well as how to make them tamper-resistant through digital signature. The OGSA-SP Secure Transport document defines well-known policies for de-facto transport-level secure communication configurations. The OGSA-SP Secure SOAP Messaging document defines analogous policies for de-facto message-level security mechanisms. If you have someone at OGF and are interested in more detail, I will be presenting the OGSA-SP documents at the OGSA Express Authentication Security Profile session on Thursday afternoon, 3:15 pm - 4:45 pm, and would enjoy discussing them further. Cheers, Duane ----- Original Message ----- From: "Alan Sill" < <mailto:Alan.Sill@ttu.edu> Alan.Sill(a)ttu.edu> To: "Duane Merrill" < <mailto:dgm4d@virginia.edu> dgm4d(a)virginia.edu>; "Andrew Grimshaw" < <mailto:grimshaw@virginia.edu> grimshaw(a)virginia.edu> Cc: "Alan Sill" < <mailto:Alan.Sill@ttu.edu> Alan.Sill(a)ttu.edu>; "Shannon Hastings" < <mailto:hastings@BMI.OSU.EDU> hastings(a)BMI.OSU.EDU>; "Hiro Kishimoto" < <mailto:hiro.kishimoto@jp.fujitsu.com> hiro.kishimoto(a)jp.fujitsu.com> Sent: Tuesday, October 16, 2007 2:36 PM Subject: OGSA-WG activities on the Express Profile > Duane and Andrew, > > Can you catch us up, including Shannon, on the activities with > respect to the Express Profile and related documents, as they might > relate to the use case described below? Shannon works with the > CaGrid group, and says that they have someone out at OGF who might be > able to interact with you about this if you are there. Meanwhile, a > few web links and a status update as regards the use case documents > and draft profile might be useful. > > Thanks, > Alan > > Begin forwarded message: > >> From: Shannon Hastings < <mailto:hastings@BMI.OSU.EDU> hastings(a)BMI.OSU.EDU> >> Date: October 16, 2007 12:43:22 PM CDT >> To: <mailto:CAGRID_USERS-L@LIST.NIH.GOV> CAGRID_USERS-L(a)LIST.NIH.GOV >> Subject: Re: operations added by Introduce >> Reply-To: caGrid Users discussion Forum < <mailto:CAGRID_USERS-L@LIST.NIH.GOV> CAGRID_USERS-L(a)LIST.NIH.GOV> >> >> Please do. We have recently become aware of another similar effort >> within the grouper group. Maybe this is the same effort. Steve is >> out >> at OGF this week so when he gets this email he can try to find those >> folks as well. >> >> Thanks, >> Shannon >> >> >> Shannon Hastings >> co-Director >> Software Research Institute >> Department of Biomedical Informatics >> Ohio State University >> >> Office: (614) 292-9461 >> Lab: (614) 292-9845 >> <mailto:hastings@bmi.osu.edu> hastings(a)bmi.osu.edu >> >> >> -----Original Message----- >> From: caGrid Users discussion Forum [mailto:CAGRID_USERS- >> <mailto:L@LIST.NIH.GOV> L(a)LIST.NIH.GOV] >> On Behalf Of Alan Sill >> Sent: Tuesday, October 16, 2007 12:27 PM >> To: <mailto:CAGRID_USERS-L@LIST.NIH.GOV> CAGRID_USERS-L(a)LIST.NIH.GOV >> Subject: Re: operations added by Introduce >> >> FYI, there is now an effort to define an architecture for >> specification, advertising and discovery of security requirements of >> exactly this nature in the context of the OGSA-WG "Express Profile" >> as a profile under WS-Security. If you are interested in this work, >> I would be happy to put you in touch with members of that group so >> you can read the profiles and use cases, and comment. >> >> Thanks, >> Alan >> >> On Oct 16, 2007, at 10:48 AM, Shannon Hastings wrote: >> >>> To be even more specific just in case you are concerned about >>> security. >>> >>> getServiceSecurityMetadata is an operation that is always public on a >>> service. What it does is tell any client what it required to talk to >>> the service. It contains no more information than that. It >>> enables a >>> client to know that he cannot talk to the service without a using TLS >>> for example. >>> >>> The other three methods are part of the wsrf spec regarding resource >>> property access. These methods will use whatever security setting >>> you >>> put on your service. If you say that your service is secure and set >>> authorization requirements at he service level in introduce, than >>> these >>> methods will also inherit this security. So you have total >>> control of >>> whether your resource properties are available. Now keep in mind, >>> there >>> are resource properties of the service, not the service properties >>> (which should be used for internal configuration and are not >>> available >>> through any operations). >>> >>> >>> >>> Shannon Hastings >>> co-Director >>> Software Research Institute >>> Department of Biomedical Informatics >>> Ohio State University >>> >>> Office: (614) 292-9461 >>> Lab: (614) 292-9845 >>> <mailto:hastings@bmi.osu.edu> hastings(a)bmi.osu.edu >>> >>> >>> -----Original Message----- >>> From: caGrid Users discussion Forum [mailto:CAGRID_USERS- >>> <mailto:L@LIST.NIH.GOV> L(a)LIST.NIH.GOV] >>> On Behalf Of Shannon Hastings >>> Sent: Tuesday, October 16, 2007 11:41 AM >>> To: <mailto:CAGRID_USERS-L@LIST.NIH.GOV> CAGRID_USERS-L(a)LIST.NIH.GOV >>> Subject: Re: operations added by Introduce >>> >>> These are required operations of any caGrid service. They are >>> provide >>> access to querying the resource properties of the main service as >>> well >>> as the security configuration of the service. This security >>> information >>> is just metadata about the requirements needed to connect to the >>> service. This enables a client to know that it will need a >>> certificate, >>> or will need to use SSL. You should not disable these operations. >>> For >>> more information on them. The resource property ones are related >>> to the >>> WS specifications and the getSecurityMetadata is a caGrid only >>> operation >>> which you can read about at caGrid.org in the Introduce technical >>> guide. >>> >>> Shannon >>> >>> >>> Shannon Hastings >>> co-Director >>> Software Research Institute >>> Department of Biomedical Informatics >>> Ohio State University >>> >>> Office: (614) 292-9461 >>> Lab: (614) 292-9845 >>> <mailto:hastings@bmi.osu.edu> hastings(a)bmi.osu.edu >>> >>> >>> -----Original Message----- >>> From: caGrid Users discussion Forum [mailto:CAGRID_USERS- >>> <mailto:L@LIST.NIH.GOV> L(a)LIST.NIH.GOV] >>> On Behalf Of Joel Schneider >>> Sent: Tuesday, October 16, 2007 11:27 AM >>> To: <mailto:CAGRID_USERS-L@LIST.NIH.GOV> CAGRID_USERS-L(a)LIST.NIH.GOV >>> Subject: operations added by Introduce >>> >>> I noticed that a service created using Introduce has the following >>> four operations, in addition to the operations I defined by hand: >>> >>> getResourceProperty >>> getMultipleResourceProperties >>> queryResourceProperties >>> getServiceSecurityMetadata >>> >>> This service in question was originally created using Introduce >>> 1.0 as >>> an analytical service, and later migrated to Introduce 1.1. >>> >>> The presence of these additional operations raises a number of >>> questions. >>> >>> 1) What is the purpose of the additional operations? >>> >>> 2) If these operations are not required by my service, is there an >>> easy >>> or recommended way to remove or disable them? >>> >>> 3) From a security perspective, I'm concerned these operations might >>> expose the service's ServiceConfiguration to a remote user. Is >>> that >>> the case? (Where is the code which implements these operations?) >>> >>> Help with these questions would be much appreciated. >>> >>> Best regards, >>> Joel >>> >>> -- >>> Joel Schneider National Marrow Donor Program >>> Software Developer (Contractor) 3001 Broadway Street NE >>> phone: 612-617-8321 Minneapolis, MN 55413 >>> email: <mailto:jschneid@nmdp.org> jschneid(a)nmdp.org <http://www.marrow.org/> http://www.marrow.org/ > > Alan Sill, Ph.D > TIGRE Senior Scientist, High Performance Computing Center > Adjunct Professor of Physics > TTU > > ==================================================================== > : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : > : e-mail: <mailto:Alan.Sill@ttu.edu> Alan.Sill(a)ttu.edu ph. 806-742-4350 fax 806-742-4358 : > ==================================================================== >

1 0

OGSA-WG sessions on Thursday and F2F meeting on Friday
by Hiro Kishimoto 16 Oct '07

16 Oct '07

Hi all, As you already know, OGSA-WG will have five consecutive sessions all at Leonesa II room on the 1st floor on Thursday, and full day F2F meeting at Blewett suite on the 7th floor on Friday. http://www.google.com/calendar/embed?src=ogsa.wg%40gmail.com If you want to join these sessions by phone, please let me know session name(s) and skype name (if you have) in advance. Thanks, -- Hiro Kishimoto

1 0

OGSA roadmap v1.1: WG final call for comments
by Hiro Kishimoto 15 Oct '07

15 Oct '07

Hi all, The OGSA roadmap v1.1 is now available for any final comments before submission to the OGF Editor. You'll find a copy of this document (draft 28) at https://forge.gridforum.org/sf/go/doc13733 If you have any comments, please bring them to OGSA-WG F2F general session on this Friday 2:30-4pm or send an email by EoB Friday, October 19. Thanks, -- Hiro Kishimoto

1 0

OGSA Glossary submitted to OGF Editor
by Treadwell, Jem 15 Oct '07

15 Oct '07

Hi, I've uploaded drafts 009 and 010 of the Glossary v1.6 to GridForge: Draft 009 has changes made following Final Call, and Draft 010 is identical, but has all the changes accepted to give us a clean base for Public Comment. If you want to see how the document has changed from v1.5, please take a look at Draft 009. I've also uploaded Draft 010 to the Editor Project, for Editor Review. Greg, I think I did this correctly, but if you need me to do anything else please let me know. Note that I resolved the tracker I opened with Paul's comment by changing the CIM definition to refer to system management, rather than resource management. Some Data definitions are still being finalized within the OGSA-D working group, and I expect to bring those into alignment following public comment. Thanks for all the contributions and support! - Jem Jem Treadwell Software Engineer HP ESS Software 856.638.6021 office | 856.638.6190 fax | jem.treadwell(a)hp.com<mailto:jem.treadwell@hp.com> 6000 Irwin Road | Mount Laurel | NJ 08054 http://www.hp.com/go/vse [cid:image001.jpg@01C80C15.5D36D420]<http://www.hp.com/go/software>

2 1

***SPAM*** IdM talk at Security Area Meeting
by Blair Dillaway 14 Oct '07

14 Oct '07

Hi All, I wanted to make sure the OGSA WG and HPCP WG members were aware of the invited talk we'll have at the Security Area meeting on Monday, the 15th, at 3:15PM in the Portland Room. Mike Jones, Microsoft's Director of Identity Partnerships, has agreed to join us to discuss Identity standards activity occurring outside the OGF and on-going efforts to ensure broad interoperability. Those of you who are interested in identity management, federations, and authentication should find this interesting. Regards, Blair Dillaway

1 0

OGSA-DAI workshop at OGF21
by Mario Antonioletti 12 Oct '07

12 Oct '07

Hi, Apologies if you receive this multiple time. This originates from Richard Sinnott the OGSA-DAI User Group chair. ................. Dear All, I am putting a workshop at OGF21 together which you may wish to attend. The basic idea is to consider the complete spectrum of data work across OGF, from the higher level vision being defined by the OGSA data architecture group; the data standards being produced such as DAIS and ByteIO; the technologies realising these standards such as OGSA-DAIv3 and then to the end user developers trying to building applications with these technologies. Think of it as microcosm of OGF as a whole. This workshop will take place at OGF21 in the Leonesa-1 room on Tuesday from 3-4.30pm. The agenda for the workshop is: 3pm INTRODUCTION - Richard Sinnott (NeSC Glasgow) 3.05pm The BIG PICTURE::OGSA Data architecture in a nutshell - Allan Luniewski (IBM) 3.25pm THE STANDARDS::OGSA Data standards (DAIS/ByteIO) - Ally Hume (EPCC) 3.45pm THE DEVELOPERS::Applying OGSA-DAIv3 in the Clinical Domain - A.Stell (NeSC Glasgow) 4.0pm WRAP UP/DISCUSSION 4.30pm CLOSE If like me you get a little lost in how OGF the different activities hang together, the idea behind this workshop is to provide a snapshot of what is going on and a reality check of the work in the data area. Rich -- Professor Richard O. Sinnott Technical Director National e-Science Centre University of Glasgow, Glasgow G12 8QQ Tel: +44-(0)141-330-8606 Fax: -8625 Mob: 0795-2376627 Email: r.sinnott(a)nesc.gla.ac.uk

1 0

Teleconference minutes - 11 October 2007 - Service level terms/Workflow
by Andreas Savva 12 Oct '07

12 Oct '07

Minutes are on gridforge: Service level terms: https://forge.gridforum.org/sf/go/doc14808 Workflow: https://forge.gridforum.org/sf/go/doc14809 -- Andreas Savva Fujitsu Laboratories Ltd

1 0

[Invitation] OGSA workflow @ 2007-10-11 09:00 - 10:00 ()
by Hiro Kishimoto 10 Oct '07

10 Oct '07

ogsa-wg(a)ogf.org, you are invited to Title: OGSA workflow Time: 2007-10-11 09:00 - 10:00 (Central Time) Calendar: Description: When: 10-11am EDT, 9-10am CDT, 7-8am PDT, 11pm-midnight JST, 3-4pm UK Dial-in numbers for Thursday: Free: +1-888-452-0308 Intl/Toll: +(210) 234-7446 PIN: 71815 See more information: - https://forge.gridforum.org/sf/go/wiki1715 Screen share service: URL: http://ogsa.glance.net/ Usage: https://forge.gridforum.org/sf/go/wiki1584 Note: ** OGF IPR POLICY APPLIES ** http://www.ogf.org/About/abt_policies.php 1) Early discussion Social study notification - https://forge.gridforum.org/sf/go/wiki1717 Note taker assignment - https://forge.gridforum.org/sf/go/wiki1848 Roll call Minutes approval and AI review (see the bottom of this agenda) Agenda bashing 2) workflow discussion (Steve McGough) Workflow session proper Suggestion: when surveying workflow systems, keep to web services based workflows (i.e., those can be accessed as web services and which can consume web services). It was observed, in an opposing view, that task based workflows are important to JSDL but are not part of (current) web services based workflows. 3) AOB Minutes approval - Aug. 9 call: https://forge.gridforum.org/sf/go/14723 - Aug. 14 F2F: https://forge.gridforum.org/sf/go/14725 Action Item review - http://forge.ogf.org/short/ogsa-wg/ailist You can view this event at http://www.google.com/calendar/event?action=VIEW&eid=dGwyNTZzMG5jaXB2aWNpbX… You are receiving this courtesy email at the account ogsa-wg(a)ogf.org because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google Calendar account at http://www.google.com/calendar/ and control your notification settings for your entire calendar.

1 0