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

Call for Abstracts: Grid and Virtualization Track (NGDC)
by Subramaniam, Ravi 15 Mar '07

15 Mar '07

Hi folks, Thanks to Hiro for permission to submit this to the OGSA-WG. This email is a call for abstracts for the Grid and Virtualization Track at the Next Generation Data Center (NGDC) conference to be held at San Francisco, August 6-9 2007 (concurrently with Linux World). Please see http://www.ngdcexpo.com/live/11/events/11SFO07A/conference for more details (and what the track scopes are). Please note that the "Call for Abstracts" is officially closed but I am making this request as the track chair to broaden the submissions. Therefore, please submit your abstracts at the earliest but no later than March 28th, 2007. Please also send these abstracts directly to me so that I can include them as appropriate for the review. The information required is indicated below. Thanks in advance for your consideration and, hopefully, your participation. Session Title: Session Abstract: Speaker Name: Speaker Bio: Contact info: email, phone, etc. Please also note that ideas for "panel format" discussions are also welcome and you can volunteer yourself and some others who you believe are topic/domain experts who would make excellent panel participants. Thanks! Ravi Ravi Subramaniam Principal Engineer, DEG-EPI-EIA Intel Corporation Ph: 408-765-3566

1 0

Latest roadmap draft 12 uploaded
by Christopher Jordan 14 Mar '07

14 Mar '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The latest draft of the Roadmap document has been uploaded to gridforge: https://forge.gridforum.org/sf/go/doc13733?nav=1 This version merges changes and comments from many individuals. It also has the latest version of Mike Behrens material on the web services context. I'd like to spend today's F2F session going over these comments and resolving any outstanding issues in the text. Thanks. Chris Jordan Data Reliability Manager San Diego Supercomputer Center ctjordan(a)sdsc.edu 858.534.8347 “Standards are like toothbrushes, everyone agrees that they’re a good idea but nobody wants to use anyone else’s.” -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF+AJaPCVtcXn6kg8RAjl7AJ47pWnZpx2uoOV339qcMuxy4v+qLwCeN4WQ sSyav5B5ygVKDw864FGWWXM= =iYKz -----END PGP SIGNATURE-----

1 0

Late Arrival & Resource Workflow Conceptualization
by Donal K. Fellows 13 Mar '07

13 Mar '07

Hi everyone! I'm sorry to say that I'm going to be arriving late at the F2F. I missed my flight due to bad weather, and so I had to go onwards a day later. I'll be arriving sometime on Wednesday afternoon, depending on how long it takes to get my bags and the hire-car, as well as the traffic (though the last time I arrived on that flight, the traffic wasn't a big deal). I'm especially annoyed to be missing the Workflow discussion and the Data grid use-cases, but I'll be in the air or on the road when those are on. I suspect I'll arrive sometime during the QoS part. Since I'm not going to be in the Workflow discussion, I'll instead write about an idea I've been working on as part of the EU BREIN project. It is an attempt to produce a conceptualization of Workflows based on (abstract) Resources instead the more conventional ideas of Services, Messages or Jobs. It's specifically intended to be a conceptualization, and as such it does not make *any* attempt to define an actual language or concrete terms for things covered by the likes of JSDL or BES (or even CIM for that matter). It's much more abstract than that right now. The document so far is available in the Workflow Design Team area of the OGSA documents tree on GridForge. I was going to put it in here, but I object to receiving large documents through email and I assume others do too. :-) Alas, the style used is not very nice; that's driven by project requirements. A few things to note about what I've done with it so far. I'm fairly sure I can capture the vast majority of resources, including things like CPUs, batch queues, applications, networks, disk space. I think I can also capture the notions of reservations, software licenses. The key to this is a three-layer model: 1: Locality - represents a space in which resources exist. 2: Resource - represents something that can be allocated, and which has some kind of usage/consumption pattern. (I do not know whether access control should be applied at the level of the locality or the resource.) 3: Aspect - represents a description of a view on a resource. I've identified three basic consumption patterns, being: * Presence Required - resource must be present in the locality for the duration of an activity using the resource * Exclusive Hold - resource must be present in locality at start of the activity, is removed/hidden from the locality while the activity is processing, and is returned to the locality when the activity completes * Consume - as with Exclusive Hold, except that upon activity completion the resource is destroyed and not returned to the locality Activities gain access to resources by describing which aspects they require and in how many localities; resources are not referred to directly (though since resources have a unique name, using that as an aspect is trivial). I don't define any logic for combining aspects (an aspect's description could be bounded in time, which is necessary for characterizing reservations using the intermediate concept of allocated time slices) or subsuming them (so an Intel Core 2 Duo is more specific than an x86, but still capable of satisfying a request for an x86), though I feel that such a logic is a Very Good Idea (if furiously difficult to define). When an activity's required aspects are satisfied, it may execute, and upon finishing execution, may create further resources in one or more localities. Such result resources (which another activity may depend upon) represent the outcome of the activity, and might also include things like a transferred dataset or a deployed software system. Result resources won't "overwrite" any resource with the same name, though they may be unnamed, in which case a new (globally?) unique name will be chosen for them at creation time. A workflow is just a set of activities that presumably depend on each other (though I suppose they don't have to) and a workflow is said to be complete when no activities are enabled (i.e. have their aspect requirements satisfiable) or the action of any enabled activity would force the overwrite of one or more named resources. It is obviously possible to define a workflow that is always creating more and more resources by having an activity that only produces unnamed resources; don't do that! :-) A few examples of actions: * Simple job execution: the action requires aspects from a single locality that correspond to the resources and application name/version that you'd expect based on a JSDL description of the job. * Dataset transfer: the action requires an aspect that corresponds to the dataset in the source locality, and another aspect that corresponds to sufficient free disk space in the target locality. If using some sort of network reservation, requiring an aspect for bandwidth from the locality/ies representing the network between the source and the target is a good idea. * Distributed metacomputing: the action is like a simple job execution on several distinct localities, and quite possibly with some extra requirements on the network locality/ies for bandwidth and/or latency. Known open questions: * Undeployment of resources that are not typically Consumed. * Access control (especially the locus of AuthZ decisions). * Whether localities are themselves resources. * How good the model of reservations is! * Whether localities need to be referred to explicitly by actions and how localities and action aspect requirements interact in the description of actions. * How much quality-of-service can be described as aspects on suitable resources. Feedback is definitely welcome on this idea, which is definitely an example of a product of the half-bakery. But I think it has merit (especially as it is not the same as either Orchestration or Choreography as I understand it; I expect these ideas to instead complement more standard workflows) especially when applied to the sorts of things which come up on the Grid. Acknowledgements: This is purely my own work, but many people were responsible for the forment of ideas from which it sprang. The following people are especially notable: * Jay Ungar, who started me thinking about abstract resources and workflows * Dean Kuo and Viktor Yarmolenko at Manchester, who started me thinking about abstract actions and reservations * My colleagues from the BREIN project, especially from the Agents group at the University of Hohenheim, who helped me understand what sorts of abstractions are needed in (some kinds of) workflows Hmm, this message has turned out to be rather longer than I originally anticipated! My apologies. Donal Fellows (stuck overnight in Amsterdam, on the grounds that it is less awful than being stuck in JFK).

1 0

GIN documentation process: First GIN-INFO draft (v.1.00) available
by Morris Riedel 13 Mar '07

13 Mar '07

Dear GIN team, I have compiled a first draft of the experience document in the area of GIN-INFO that is available from: http://indico.cern.ch/materialDisplay.py?sessionId=4 <http://indico.cern.ch/materialDisplay.py?sessionId=4&materialId=0&c onfId=12489> &materialId=0&confId=12489 This document is not ready yet - I'm currently waiting for feedback, especially from people of GIN-INFO (I got Laurence comments already). This document will be discussed in my session tomorrow - so have a look at the document if possible to provide feedback. Furthermore, I started a similar document for GIN-JOBS already, while Dane Skow plans to do the same for GIN-AUTH. An early draft of GIN-JOBS will be presented tomorrow as well. Early drafts of GIN-DATA and GIN-OPS will be next after GIN-JOBS. So, people that would like to contribute to these documents should send me the following: (1) name (2) affiliation (3) three sentences what you did in GIN (4) documents to which you would like to contribute Finally, some of the OGSA-WG members have already stated interest in the GIN-INFO experience document - so let us get this ready as soon as possible. More details tomorrow during the session. CU at GIN@CERN, Morris Riedel OMII - Europe Leader interoperability/interoperation task ---------------------------------------------------------------------------- ---- Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Central Institute of Applied Mathematics Research Centre Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: <mailto:m.riedel@fz-juelich.de> m.riedel(a)fz-juelich.de Info: <http://www.fz-juelich.de/zam/ZAMPeople/riedel> http://www.fz-juelich.de/zam/ZAMPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel 'We work to improve ourselves and the rest of mankind.'

1 0

Announcing Reference Model WG
by Strong, Paul 12 Mar '07

12 Mar '07

All, Following the Birds of a Feather meeting at OGF19 and approval by the GFSG last week, we are delighted to announce the creation of the Reference Model Working Group of the OGF. This group will build on the OGSA Glossary and the EGA Reference Model, a model that allows the description of grids (services and resources) and how they can be managed, in terms of an intuitive set of components, relationships and life cycles. We will be formalizing this work in UML, comparing and mapping to extant OGF and external standards, and exploring additional representations (RDF/OWL) and serializations (RDFXML, SML etc.). More details about our goals can be found at http://www.ogf.org/gf/group_info/view.php?group=rm-wg. For those of you who are interested please do join the working group. You can subscribe to the email alias here - http://www.ogf.org/mailman/listinfo/rm-wg, or access the project in GridForge here - http://forge.gridforum.org/sf/projects/rm-wg. Our first meeting will be by telephone conference call on Weds 21 March 2007, at 3PM GMT, 8AM PDT, 11AM EDT (Note US daylight savings has kicked in earlier this year). Call in details will be on the group Wiki here - http://forge.gridforum.org/sf/wiki/do/viewPage/projects.rm-wg/wiki/HomeP age. We look forward to your joining us for what promises to be and interesting and challenging project! Regards David Snelling and Paul Strong Co-Chairs, Reference Model Working Group

1 0

No call on March 12
by Hiro Kishimoto 12 Mar '07

12 Mar '07

Hi all, Since we will have 3-day F2F meeting this week, we won't have Monday call on March 12. https://forge.gridforum.org/sf/go/wiki1685 See you in the SF bay area, -- Hiro Kishimoto

1 0

Draft, Informational, Security Profile
by Mark Morgan 09 Mar '07

09 Mar '07

Ladies and Gentlemen, Please find attached a draft copy of an informational document detailing a recommendation that the GBG group at the University of Virginia would like to discuss next week at the OGSA F2F. To the best of our knowledge, based on documents sent by Mr. Ian Foster, this document describes ways of filling in gaps that exist in the current OGSA security documents that are consistent with Globus GT 4. -Mark and Duane -- Mark Morgan Research Scientist Department of Computer Science University of Virginia http://www.cs.virginia.edu mmm2a(a)virginia.edu (434) 982-2047

4 6

Re: [ogsa-wg] Draft, Informational, Security Profile
by Duane Merrill III 09 Mar '07

09 Mar '07

Sorry, the 2nd to last line in my response should read: "there must be agreement between the EPR's address field and any such server subject-(alt-)names in embedded EPR key/cert information that is specified for transport endpoint verification" -Duane ----- Original Message ----- From: Duane Merrill III To: Frank Siebenlist ; Blair Dillaway Cc: ogsa-wg(a)ggf.org Sent: Friday, March 09, 2007 12:28 PM Subject: Re: [ogsa-wg] Draft, Informational, Security Profile ----- Original Message ----- From: "Frank Siebenlist" <franks(a)mcs.anl.gov> > * Blair mentioned it already, but just to clarify that the embedding of > key-info in the EPR allows one to use normal user-certs for ssl/tls > servers and to enforce an equivalent authorization on the to-be-expected > server's subject(-alt)-name. Section 2.1.i seems to hint at the same in > the BSP-core discussion. >> ----- Original Message ----- >> From: "Blair Dillaway" <blaird(a)microsoft.com> >> 1. I have discussed the motivating use cases for OGSA-BSP Core with >> Frank Siebenlist. This was developed to support validation of the desired >> TLS/SSL server where the server cert doesn't contain info corresponding >> to the service location. I happen to think standardizing on such a >> mechanism may be more important when using message-level security, >> but that may require some additional work as you mention. Very interesting. I had no idea that the OGSA BSP-Core was specifically motivated for SSL/TLS transport level security. I had just assumed that the profile was primarily addressing an intuitive approach for communicating key/certificate information to clients for use in SOAP message-level secure commmunication. (The words "SSL" or "TLS" never appear in the document, and "transport" appears once in line 107 in a manner that would appear to be descriptive of the OGSA BSP-SC profile, rather than the Core profile.) In fact, it seems that the OGSA HPC Basic Profile document made the same initial assumption that I did, as it reads: Note: The OGSA Basic Security Profile 1.0 - Core specification is not used as that addresses the binding of key information to an endpoint reference [in WS-Addressing], which is not relevant when using transport layer security. This further evidences the need for more specificity in the BSP-Core profile for the intent-of-use of the embedded key (cert) information. (For example, a client may want to see two certificates within the endpoint references that it consumes: one to verify the SSL/TLS endpoint, and the other to authenticate the individual, possibly-mobile, remote resource.) We would suggest that the OGSA BSP-SC be updated to explicitly reflect this interaction with the (proposed updates to the) BSP-Core; specifically that there must be agreement between any such server subject-(alt-)names in embedded EPR key/cert information that is specified for transport endpoint verification. By doing this, the application of these two profiles would explicitly address your original tranport security motivations. -Duane

1 0

F2F meeting agenda
by Hiro Kishimoto 08 Mar '07

08 Mar '07

Hi all, I've got a request to move "EMS design team" session, now scheduled on March 14 Wednesday Morning, to March 15 or 16. Is it possible to switch this with workflow session on Friday March 16 Friday Morning? Michel Drescher and Steve McGough: Does Wednesday morning work for workflow design team? If it does now work for you, we may switch with "general session." Anyway, Awe will fix all F2F agenda by this Thursday call (second slot 8-9am CST) at latest. Thanks, -- Hiro Kishimoto

1 1

SAML profile of XACML is NOT deprecated
by David Chadwick 08 Mar '07

08 Mar '07

Here is the original message from Anne Anderson regards David -------- Original Message -------- Subject: Re: [OGSA-AUTHZ] Web Services (Policy?) profile of/for XACML Date: Mon, 26 Feb 2007 14:01:44 -0500 From: Anne Anderson - Sun Microsystems <Anne.Anderson(a)sun.com> Reply-To: Anne.Anderson(a)sun.com Organisation: Sun Microsystems, Inc. To: David Chadwick <d.w.chadwick(a)kent.ac.uk> CC: Yuri Demchenko <demch(a)science.uva.nl>, OGSA AUTHZ WG <ogsa-authz-wg(a)ogf.org> References: <45D1DABA.4050507(a)kent.ac.uk> <45DC756B.5090104(a)science.uva.nl> <45DCAB9B.7080508(a)kent.ac.uk> The original SAML 1.0 Authorization Decision Query and Statement were "frozen" as of SAML 2.0, with a reference to the "SAML 2.0 profile of XACML v2.0" as a suggested replacement. The "SAML 2.0 profile of XACML v2.0" is very much alive and has not been deprecated; it is a full OASIS and ITU-T Standard. You can find a copy on the XACML TC Home Page along with the other XACML 2.0 specifications: http://www.oasis-open.org/apps/org/workgroup/xacml/manage/edit_notes.php#XA…. There were some errors in the spec and schemas that are corrected in the "SAML 2.0 profile of XACML v2.0 Errata" available at http://www.oasis-open.org/committees/download.php/15447/xacml-2.0-saml-erra… The XACML TC is updating the "SAML 2.0 profile of XACML" as part of its XACML 3.0 release. The updates are intended to be backwards compatible, and consist primarily of some additions to support the XACML 3.0 Administrative Policy specification, such as the ability for a PEP to send a policy to be evaluated along with the request context. The draft of this update is available at http://www.oasis-open.org/committees/download.php/18921/xacml-2.0-profile-s… I should be issuing a new draft before too long. Please let me know if you have any further questions. Regards, Anne David Chadwick wrote On 02/21/07 15:29,: > Hi Yuri > > firstly we have a lot of opportunity to feed our comments into Anne, the > author, and I am sure she will be very receptive to our helpful input. > > Concerning its purpose, it can be used in negotiation for the sender to > say what his requirement are from the other party, and what his > capabilities are for providing a service to the other party. However, > this is not really what we want from this service. We simply want the > ability to provide an XACML request context in a secure manner to a > remote PDP, and to obtain an XACML response context from the PDP. Which > is why the SAML profile (that is now deprecated) was actually ideal for > us (and why my first OGF spec was based on it). So my question to Anne > would be, Can we make sure this new spec has the same functionality (at > least) as the previous SAML spec. > > regards > > David > > > Yuri Demchenko wrote: > >> Hi David, >> >> I looked at the document your sent and was a bit confused to position >> it among other standards in use and our work. >> >> Before we can discuss some minor detail, I want to say that title is a >> bit misleading. They call it "Web Services Profile of XACML >> (WS-XACML)" but actually it is Web Services Policy (WSP) >> profile/extensions for (using) XACML in WSP style policy definition. >> >> They provided good use cases in Introduction, and correctly described >> XACML AuthZ token (section 2). >> >> For me, it is not clear their definition of XACMLAuthZAssertion >> (section 3). Is this an assertion or policy statement? >> >> "An XACMLAuthzAssertion represents an XACML authorization, access >> control, or privacy policy that applies to the target of the >> wsp:Policy instance in which it appears. The Assertion MAY be used by >> a Web Service to express or publish its authorization, access control, >> or privacy requirements or its capability of complying with >> requirements imposed by a client. The Assertion MAY be used by a Web >> Services client to express or publish its authorization, access >> control, or privacy requirements requirements or its capability of >> complying with requirements imposed by a Web Service. Two instances of >> such an Assertion MAY be matched to determine whether they are >> compatible, and, if so, which requirements and capabilities are >> compatible." >> >> Also I didn't find support for so much expected cryptographically >> valid/ensured attributes. >> >> So, what possibilities do we have to give our comments to the author? >> >> Yuri >> >> >> David Chadwick wrote: >> >>> is attached. >>> >>> >>> ------------------------------------------------------------------------ >>> >>> -- >>> ogsa-authz-wg mailing list >>> ogsa-authz-wg(a)ogf.org >>> http://www.ogf.org/mailman/listinfo/ogsa-authz-wg >> >> >> > -- Anne H. Anderson Email: Anne.Anderson(a)Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692 -- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick(a)kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************

2 1