March 2009 - pgi-wg - lists.ogf.org

Re: [Pgi-wg] REMINDER: Agenda and Numbers: PGI Security TelCon 4pm(CET) TODAY
by Steven Newhouse 27 Mar '09

27 Mar '09

> (2) > PGI Security Talk for Tuesday next week (MWSG Group Meeting, Zürich) We should be able to provide a dialin for this part of the meeting and the discussion that follows. Steven

2 1

Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman)
by m.riedel＠fz-juelich.de 27 Mar '09

27 Mar '09

Right, but if I have an EPR obtained from UNICORE-BES (wsa:To + referenceproperties) that a client of ARC can't handle it rightly would break our desired interop by maybe just using wsa:To URIs... ...it seems like we have a lot wheels to work on...one after another. Let's not give up - at least the right set of people are this time together in the group representing the right middleware assembly... I'm delighted to join the call soon... In CET is currently 3:30 p.m. Take care, Morris -------------------------------------------------------------------------------- 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: m.riedel(a)fz-juelich.de Info: 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.' ----- Original Message ----- From: Duane Merrill <dgm4d(a)virginia.edu> Date: Friday, March 20, 2009 3:22 pm Subject: Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman) > > So I see a demand that we discuss if our services are contacted with > > WS-Addressing or not. > > > In case this thread turns into a referendum on the merits of WS- > Addressing,I would like to point out that that the Basic Execution > Service (BES) spec > incorporates EPRs into its interface. > > So, if PGI has apsirations to discuss anything that resembles BES, > supportfor WS-Addressing would be a Good Idea if for no other > other reason that to > not have to completely re-invent the BES wheel (again). > > -Duane > ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

4 3

Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman)
by m.riedel＠fz-juelich.de 27 Mar '09

27 Mar '09

Ok, I understand much better know. So I see a demand that we discuss if our services are contacted with WS-Addressing or not. Q: How does ARC services then distinguish one instance from another if only one URL is used?! you don't seem to use referenceproperties then, instead adding to the url resource-instance ids?! Take care, Morris -------------------------------------------------------------------------------- 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: m.riedel(a)fz-juelich.de Info: 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.' ----- Original Message ----- From: Aleksandr Konstantinov <aleksandr.konstantinov(a)fys.uio.no> Date: Friday, March 20, 2009 12:44 pm Subject: Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman) > On Friday 20 March 2009 12:24, Morris Riedel wrote: > > Hi, > > > > >- As I > > >-explained in an earlier mail, "limited" here means that the > PGI profile > > >-shall precisely described in a self-contained way the minimum > set of EPR > > >-elements which must be supported by conforming inplementations. > > > > So far, I guess we only depend on the wsa:To element of the > specification> with the URI making it the minimum element of it. > > > > With WS-Naming this would be expanded using wsa:metadata and ws- > naming> elements of course. > > > > Isn't our usual procedure to take the URI - encode an EPR (with > wsa:To) and > > send it to the BES systems? Or is this maybe only my narrow > UNICORE view of > > how we do it? > > > > Q: What is meant by accessing a CREAM-BES and A-REX with URI > (instead of > > EPRs)? > > ARC does not rely on EPR present in SOAP messages header sent to > BES service. > ARC clients do put EPRs into headers for compatibility. > Hosting environment of ARC services may perform routing of > messages depending > on wsa:To element of EPR. > To make it short - we can live with and without EPRs. > AFAIR BES specs say nothing about if BES service has to be > contacted using EPRs. > > > > A.K. > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg > ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

4 4

REMINDER: Agenda and Numbers: PGI Security TelCon 4pm (CET) TODAY
by Morris Riedel 27 Mar '09

27 Mar '09

Hi PGI team, Just a short reminder for our TelCon: TODAY - 4 pm CET (1 hour) Call-in details as follow: via Skype call +9900827049931906 (free of charge) ordinary phone numbers (local rates) with the 9931906 conference number: Austria 0820 401 15470 Belgium 0703 57 134 France 0826 109 071 Germany +49 (0) 180 500 9527 Switzerland 0848 560 397 Proposed agenda: (1) OGF PGI Security model (see emails) and 'plumbing' approach (2) PGI Security Talk for Tuesday next week (MWSG Group Meeting, Zürich) (3) Shortly the matrix about security in the wiki (4) PGI abbreviations/terms list provided by Johannes (5) AOB Please feel free to contact me if you would like to add certain agenda topics. I encourage all security folks to further discuss our issues on the mailing list in order to save valuable time for questions/clarifications during the TelCon. 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(a)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)

1 0

More information on Security Plumbings (with GLUE dependencies)
by Morris Riedel 27 Mar '09

27 Mar '09

Hi team, So in my mail from yesterday evening, I referred again to the plumbings and before I will draft now slides/factsheets I would like to shortly point out again what I mean with it - maybe more explicitly - although this has been already discussed with several AuthZ specialists in prior OGFs or other events (e.g. Valerio Venturi, etc.). Major idea: Simple + Stupid - not cracking the security dilemma, but creating a significant step towards DEFINING the common security models/plumbings: # First of all, the clients choose the client technology they like or find convenient for their science (maybe even business) - I think that's something where we all agree to. ###### 1 - Pluming Type: Authentication (either-or) = TWO choices here: PGI_AUTHN_ENDENTITY or PGI_AUTHN_PROXIES (meaning one has to support the chain checkings) # an end-user uses this client with an PGI out-of-band mechanism (maybe LDAP queries) to retrieve GLUE-based information about a certain endpoint getting: # endpoint contact information (i.e. BES URL) AND # GLUE SECURITY.AUTHENTICATION capability of this endpoint # The value of this capability is either PGI_AUTHN_ENDENTITY or PGI_AUTHN_PROXIES # The client know how to contact the endpoint on the TLS level then, which is in PGI the foundation for AUTHN ###### 2 - Plumbing Type: Attibute-based AuthZ (at least one of it) = TWO choices here: PGI_AUTHZ_AC or PGI_AUTHZ_SAML # an end-user uses his client again (or retrieved information with the first request) with an PGI out-of-band mechanism (maybe LDAP queries) to retrieve GLUE-based information about a certain endpoint getting: apart from the above information: # GLUE SECURITY.AUTHORIZATION capability of this endpoint # The value of this capability is AT LEAST ONE of PGI_AUTHZ_AC, PGI_AUTHZ_SAML - maybe even both # The client knows how the attributes have to be transported to the endpoint then so that the endpoint understands them and uses them for attr-authz based on resource-owner policies. #### The bottom line is that we just have to define a few bits and pieces precisely that are PGI_AUTHN_ENDENTITY, PGI_AUTHN_PROXIES , PGI_AUTHZ_AC, PGI_AUTHZ_SAML. Each of it well-defined with respect to used standards, IETF RFCs, OASIS SAML, like Etienne listed... With that we significantly narrow down the possibilities in terms of security while we have two different types of plumbings that are easy to understand: AuthN + Attr-AuthZ. Maybe we need another plumbing because of the difference of using the incompatible general proxies and GSI proxies on the TLS level, but both are part of the AuthN plumbing type. Maybe in future this incompatibility is fixed and then one plumbing might be just removed without changing standards. ### Looking from the end-user point of view seeing a united federation of Grid systems, the user uses his client that may only support one plumbing in terms of attr-AuthZ . In that matter the client only queries from the out-of-band-information service GLUE-described endpoints that only supports these systems that match with the supported plumbings from the client (and matched other requirements like cores/memory/interconnection of course). Of course, we have to agree on the transported attribute structure - but the deployment of plumbings is policy of the respective infrastructures. The infrastructures may even setup two endpoints with different plumbings to support more clients that is still better than having a complete middleware co-existence at the resource level... Hence, the idea of the plumbings was to have a relatively easy to understand mechanism to describe what end-user clients require to understand when performing interoperability use cases. Also, as you see in my figures, the security plumbings are close to the information plumbing (i.e. GLUE) meaning that both have to be installed in a working house. I hope the idea of plumbings got much clearer now, but I will try to provide some figures for the telcon this afternoon. Like the reference model term, also the plumbings term can be changed to something more understandable. Of course, the plumbings are only my suggestion coming from GIN interop. use case experience and working in the field of interop for many years now - of course its still subject to discussion - but it has much potential to bringing us closer together NOW instead of waiting for a huge common security framework in the future that may not even be defined (+deployed!) before the Grid fundings are stopped... Finally, with looking from a slightly distance on the group, I'm happy that we are still in the process of jointly discussing in the group and no one leaves and thus I'm confident that we can act as a team to provide something useful to the Grid community, which is maybe not the perfect solution in terms of security, but a good step forward bridging different worlds - achieving interoperability at least between several Grid islands... Your co-chair, 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(a)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)

1 0

FW: OGF PGI - Security Model
by Morris Riedel 26 Mar '09

26 Mar '09

Hi interop-friends, firstly sorry again for missing the last days. I have seen many comments since then and unfortunately see that the different threads had been united again mixing things up a bit (maybe it was nevertheless useful). Finally Steven made a good point with 2-3 sec. models out of n^n ones. So finally we have reached to the ideas of my suggestions of having well-defined different security 'plumbings' (aka 2-3 well-defined security models). I don't care about its precise name... I just used this term 'plumbings' because it had no pre-definition in security, please compare the vertical lines in the interoperability reference model - they are just more simpler defined in terms of AUTHN and ATTRIBUTE-AUTHZ than the long list presented by Etienne but very much of its content is the same. I presented this since OGF23&OGF24 within GIN with the two ways (left AC and right SAML) and the open issues to work on, but never had chance to write it down in written text yet: http://www.ogf.org/OGF24/materials/1409/2008-09-16_GIN_SessionTwo_OGF24_Ried el_v1.pdf Slide 6 and others... :-) Especially on this slide 6, even outsiders of our production Grids (like Chris Smith) understood the meaning of the slide and I got positive feedback on this from numerous sides. We all want to reach interoperability here in this group. We want to do this for certain interop applications. We shouldn't underestimate the power of the combination of the different security elements - nailing down the currently typical ways of using TLS with certs, Attr-Authz, Attributes, Constraints/Restrictions in conjunction are already powerful. We will have precise PGI definition of aligning such building blocks even if there are two ways in the end - but there are less than n^n ways that are currently out there in the security field combining different blocks, profiles, etc.... Also, what the middleware supports and what is then deployed in turn on particular production Grids are both different stories! For instance, UNICORE can be used with the proxy-style (plumbing) enabling interoperability with gLite, ARC, NAREGI. We have done this for many interop use cases, for instance with portals requiring proxies. However, there should be also another full X.509 (plumbing) available where other common approaches can be used and then expressed correctly via GLUE in interops as well used other infrastructures with different policies. I even foresee that there could be used more than one plumbing in parallel. We may have still single islands in a way - but we also come closer together, which is a good first step towards the right direction and my suggestion to move forward in this complex security discussion since its beginning. Which particular plumbings of both common approaches are then used in production Grids is policy of the respective deployments of the middlewares and may even depend on the underlying interop application use cases which should be our most significant drivers (!) - BUT the main point is that we know where we talking about in interop work without having n ^ n different security setups available! Only one short example: # There is one DB with attribute information about of end-users (used by VOMS) # Agreeing on the attribute semantics&Structure is important # VOMS support interface for retrieving AC and also SAML assertions # There are two ways of transporting the attributes that come out of the same DB (used for later attr-authZ) # Both transports have correct AuthN mechanisms (clarifies AuthN+ID-authZ) # In the end using different plumbings, but the same attributes are then evaluated against a policy describing maybe having equal policies based on the same transported attributes of the same DB (re-alignment!) # In the end what matter are the attributes a user has and what the policy decides to do with them (if its XACML, ACLs, etc. is unimportant here), but we should talk about the same things once we evaluate attributes. I try to provide you more figures, etc. hopefully tomorrow - but on my slides a lot of it has been already presented numerous times... we just have to nail it down - but in a more KISS style = Keep in Simple and Sweet/Stupid! Your co-chair, 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(a)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(a)ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of >-Steven Newhouse >-Sent: Thursday, March 26, 2009 7:16 PM >-To: Moreno Marzolla; Duane Merrill >-Cc: pgi-wg(a)ogf.org; edges-na3(a)mail.edges-grid.eu; lodygens(a)lal.in2p3.fr >-Subject: Re: [Pgi-wg] OGF PGI - Security Model >- >-> Having to build >-> adapters to translate (if possible) credentials in different formats >-is >-> a compromise which is more reasonable than having to wait for all the >-> middlewares of the world to move towards a common security >-> infrastructure. >- >-In the short term... documenting and defining the 2 or 3 security models >-is real progress. If a service only supports one of these I do not see >-this as a problem - for all the reasons given. Providing credential >-translation services to provide 'shims' (or bridges between these >-islands) as an interim solution makes this work. Its a low risk to >-individual services - they maintain their current stability - and can >-migrate over time to support both or the most 'popular' one - let the >-market decide! >- >-Each service can then advertise the mechanisms it supports and clients >-can locate credential translation services as required. >-_______________________________________________ >-Pgi-wg mailing list >-Pgi-wg(a)ogf.org >-http://www.ogf.org/mailman/listinfo/pgi-wg

1 0

VO management in OSG
by Oxana Smirnova 24 Mar '09

24 Mar '09

Hi all, I just attended a talk at CHEP09 presenting something called SVOPME - an environment to manage VO privileges in Open Science Grid (which is a production Grid infrastructure, admittedly underrepresented in OGF). Can be of interest for us. See the slides here: http://indico.cern.ch/contributionDisplay.py?contribId=188&sessionId=62&con… Cheers, Oxana

1 0

Apologies for not contribute to discussions
by Morris Riedel 24 Mar '09

24 Mar '09

Howdy folks, I mentioned this to some people already - but just for the understanding of others - I'm involved in JSC in a triple AAA priority event related to our fundings for the next years - therefore I can't work on PGI until Thursday. Please contact Shahbaz Memon (m.memon(a)fz-juelich.de) in urgent cases about BES. Please contact Shiraz Memon (a.memon(a)fz-juelich.de) in urgent cases about GLUE. However, I'm keen to have another Security Phone Con on Friday based on Factsheets prepared on Thursday. 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(a)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)

1 0

Re: [Pgi-wg] Sec: Agreement on attributetransportmechanismsforAttrAuthZ
by m.riedel＠fz-juelich.de 23 Mar '09

23 Mar '09

hi, can you not just use the full end-entity certs with extensions (i.e. put ACs there=? Take care, Morris -------------------------------------------------------------------------------- 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: m.riedel(a)fz-juelich.de Info: 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.' ----- Original Message ----- From: Moreno Marzolla <moreno.marzolla(a)pd.infn.it> Date: Friday, March 20, 2009 3:55 pm Subject: Re: [Pgi-wg] Sec: Agreement on attributetransportmechanismsforAttrAuthZ > m.riedel(a)fz-juelich.de wrote: > > Hi, > > > >> - This is the problem you mentioned which we experienced during > the > > OMII-EU project: BES clients were not executing the delegation > > operation, so the service did not have any delegated credentials > to use. > > We then implemented a horrible workaround in CREAM which was > fine for > > demonstration purposes, but unfortunately can not be applied for > any > > real use. > > > > > > ok, that's interesting - if you don't extract the proxy > obviously then from TLS level during AuthN steps - why is there > still a proxy support needed on the TLS level then?! > > I answer your question according to the understanding I just > gained from > our security experts, so bear with me :-) > The gLite middleware relies on VOMS extensions to associate roles > to > users according to the VO they belong to. If you use plain X509 > certificates, of course you don't have any VO information there, > so it > is not possible for services to assign roles to the bearer of > those > certificates. > Suppose you want to submit a job to CREAM, and the job needs to > stage > external data to/from a service which DOES require VO extensions > in > order to perform authorization decisions. In this situation you > need at > least to delegate to CREAM a certificate with VOMS extensions (the > delegated certificate will be used by CREAM to access external > resources > on behalf of the user). > Of course, if you have an X509 certificate signed by a > "conventional" > certification authority, you cannot stick VOMS extensions inside > it. For > this reasons, when gLite users want to interact with CREAM > directly, > they first create a VOMS proxy certificate via the voms-proxy-init > command. Thus, using a proxy to interact with CREAM is only needed > to > have VOMS extensions inside the credential used to interact with > the > service. > If your job does not require to access any external service, OR if > that > external service does not rely on VOMS extensions, then you are > perfectly fine using plain X509 certificates only. > > Moreno. > > -- > Moreno Marzolla > INFN Sezione di Padova, via Marzolo 8, 35131 PADOVA, Italy > EMail: moreno.marzolla(a)pd.infn.it Phone: +39 049 8277103 > WWW : http://www.dsi.unive.it/~marzolla Fax : +39 049 8756233 > > ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

3 4

Re: [Pgi-wg] Sec: Agreement on SOAP and authentication
by Jens Jensen 21 Mar '09

21 Mar '09

Morris Riedel wrote: > Hi security folks, > > > reading certain elements of the IIRM, strawman, and following discussions > on the list - I see there is still no common agreement on SOAP / HTTP(S) in > some areas. > Trying to pick up the thread, I have read it now (not necessarily understood :-)... I skimmed PGI_COMM v0.3, mainly asking to clarify whether things are in scope. Note the difference between PKC validation is that in Globusy grids the web service must have the whole CA certificate chain installed from the EE cert to a self signed root; for a proxy the client is required to supplement the chain by sending the intermediate certificates (viz, the user certificate and intermediate proxies). There are cases where this provides additional security. Thus a web service provider needs the CA hierarchy installed - this is (being) documented by CAOPS. In a sense the proxy hierarchy underneath it is more dynamic. In a sense this makes it more usable at the cost of some loss of security. One other point, nobody so far (that I could see) mentioned the gLite delegation service. This would provide a way to keep delegation but still have SSL/TLS sockets. One other point. Most HTTPS/SOAP connections in practice are opened on demand. Every time the client makes a call (I don't believe anyone ever implemented notifications, instantiated from the server), a new SSL socket is negotiated. This turns out to be comparatively expensive, and there are suggestions for how to improve this. Is this within the scope of the document? There are proposals for streaming SOAP, is that within the scope of this document? Support for this would be useful for some of our applications. One other point, turns out there is some debate about the role of the trust anchors in SAML-based trust federations (Shibboleth ones specifically). Their approach is in practice often distinct from typical grid PKIs. Is this within the scope of the document? Is the work supposed to be specific to SOAP or are other things carried by HTTPS or HTTPG relevant? One thing that would be useful is to have an overview of which WS-* are actually implemented in usable libraries. I will not touch WS-Anything unless it has a (preferably open source) implementation in C++ which interoperates with a Java ditto (usually Java supports WS-Anything first). Regards --jens

1 0