[Pgi-wg] Sec: Agreement on attribute transport mechanismsforAttrAuthZ

[weizhong qiang]

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 at 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 at cern.ch]
> *Sent:* Friday, March 20, 2009 11:49 AM
> *To:* weizhong qiang; Morris Riedel
> *Cc:* pgi-wg at 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 at ogf.org
> http://www.ogf.org/mailman/listinfo/pgi-wg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/pgi-wg/attachments/20090320/a773c65e/attachment.html