hi, PGI_TLS and PGI_GSI were mentioned by you in a few thread. Again, I would like clarify something from my point of view. Do you mean PGI_GSI the services/clients that talk to each other by using GSSAPI? or just talk to each other based on TLS while using proxy certificate. I think there is difference between them. So I would divide them into branch by using your notation: PGI_TLS PGI_TLS_PROXY (the notation is also in the virginia strawman) PGI_GSI 2009/3/20 Morris Riedel <m.riedel@fz-juelich.de>
Hi,
- My personal thinking is, since we are talking about PGI or interoperability, we probably do need to change the current implementation if it can not satisfy interoperability, while keeping the principle that the change should be as little as possible.
In terms of little changes I agree – but I consider PGI_TLS / PGI_GSI as massive changes.
For instance, we have developed a UNICORE Gateway (for AuthN) that works with PGI_TLS naturally – and PGI_GSI more recently providing of course not FULL delegation support per hop, but proxies are supported on GSI-TLS level.
However, can we expect that you one contact a CREAM-BES any time soon with full end-entity credentials or any other gLite component?
The CREAM service has been tested (by some of our colleagues) . And the result shows CREAM service requires "limited" proxy certificate (proxy with "CN=proxy") when it doing data transfer. Inherently, because of forwarding mechanisms internally – proxies are
necessary probably.
But maybe that’s my old interop* knowledge – so let’s clarify again…
Some statements that need clarification:
Note: UNICORE can be contacted using PGI_TLS and PGI_GSI – the same is planned for GENESIS-II as far as I remember.
"and PGI_GSI" means PGI_TLS_PROXY or PGI_GSI?
From out experience about testing against UNICORE service, it uses PGI_TLS_PROXY.
Q: Do gLite also supports pure PGI_TLS apart from PGI_GSI?
Q: Do ARC also supports pure PGI_TLS apart from PGI_GSI?
PGI_TLS PGI_TLS_PROXY possible to support PGI_GSI (the definition I mentioned)
Q: Do we really imply that PGI-compliance means that both PGI_GSI and pure PGI_TLS have to be supported? Or we rather go the plumbing way of defining either or as MANDATORY and as MAY both supported (two plumbings).
I see PGI_TLS_PROXY should be mandatory. Regards, Weizhong
Thanks for clarification,
Morris
*From:* Steven Newhouse [mailto:Steven.Newhouse@cern.ch] *Sent:* Friday, March 20, 2009 11:49 AM *To:* weizhong qiang; Morris Riedel *Cc:* pgi-wg@ogf.org *Subject:* RE: [Pgi-wg] Sec: Agreement on attribute transport mechanismsforAttrAuthZ
My personal thinking is, since we are talking about PGI or interoperability, we probably do need to change the current implementation if it can not satisfy interoperability, while keeping the principle that the change should be as little as possible.
And to clearly describe the interoperability benefits that will be derived (i.e. systems and communities) by making that change.
Steven
_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg