[Pgi-wg] Sec: Agreement on attribute transportmechanismsforAttrAuthZ

[m.riedel at fz-juelich.de]

Howdy,

>-PGI_TLS_PROXY (the notation is also in the virginia strawman)
>-PGI_GSI

 so in this context what is the difference on TLS itself w/o considering different APIs?!

Good  point in checking this out - I'm still think its rather the same.

Thanks for clarification,
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 at 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: weizhong qiang <weizhongqiang at gmail.com>
Date: Friday, March 20, 2009 1:10 pm
Subject: Re: [Pgi-wg] Sec: Agreement on attribute transport mechanismsforAttrAuthZ

> 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 [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
> >
> >
> 



-------------------------------------------------------------------
-------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich

Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe
Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt,
Dr. Sebastian M. Schmidt
-------------------------------------------------------------------
-------------------------------------------------------------------