PGI-WG: first session 26 May 2009, 15.30h (EST)

Security discussion
First authentication setup
Transport level

client
server
and capability to describe both

first authn plumbing
several systems 
agreed to the setup in slide 15
proxy chain checking

climbing the proxy chain is what you ahve to adapt

using GLUE, we can describe an nail down

we cannot agree on ONE

describing the different ones with GLUE

problem:
related to the first plumbing
relates to the GSI way of doing it

proxy chain mechanism is essentally the same

difference to the second one

Steve:
TLS/GSI deprecated in most of the roadmaps

Etienne:
configuration files on the VOMS servers on the user interface is good enough to accept rfc compliant proxies
since saml is supposed 
we should not use rfc complian proxies since many services have problems with

Andrew:
SRM, gridftp only work with old style proxies

maybe in the heart of the codes is the old style proxies

Steve:
non trivial amount of time
removing the old ones is a much longe prcess

Etienne:
only accfept Globus proxies
if you replace the gt2 with gt4 libraries
both accept globus style proxies

Steve:
Are those implementation running the old proxies and new proxies simultaneously?

Not having to deal with the old proxies...

SRM implementers
Morris:
 ->  point for tomorrow's session

GSI: run into a lot of problems
covered by the job submission itself
the last issue was srm

Major standard plus sub standards

Question:
a) PGI security, PGI Proxy security, PGI GSI security

b) just one big document

Steve:
three specs
most popular first
than the next one
the third one will be deprecated soon

Mark:
if you are going to supüort multipe renderings:
should have a simple spec

Andrew:
specified or profiled in any way?

Mark:
you ahve to make a decision
how you find out 
wether or not a client can talk to an endpoint

Andrew:
there needs to be a mechanism 

Morris:
GLUE capability

Mark:
in terms of interoperability
the client has to know if he has to talk to the server

Andrew:
Should there be a default?

Mark:
another way of handeling the same problem

Morris:
nothing could be the default

the compromize is the third entity

there are eprs without any security description

Steve:

two proxies: GSI and TLS proxies

nobody is saying to get rid of proxies

deprecate old style GSI proxies


question:
standards based profile around?

Steve:
most software components that use the old GSI proxies should deprecate the GSI proxies

people will change their default mecahnisms and software gets updated within the next (up to) 26 months

Steve:
OSG is it's way out of GRAM

how quickly cream is being adopted

OSG is out of production

David:
pre webservices Globus endpoint: is this relevant to this discussion

Morris:
is out ofe scope

Steve:
not worriing about profiling the old style proxies

don't panic

Morris:
will make interoperability

outcome of the question how we profile -> Mark

it seems to be the only way of doing it

Mark:
ie. additional rendering document in OGSA

separate document says how to do it

three security documents better


Authorization:
one setup related to authz
attribute based authz, not identity based

Steve:
did we decide anything

do we need to profile the old style GSI proxies?
related to SRM communtiy

Morris:
they yall moved to CREAM


Steve:
OCGCE
half to deprecation

what is the half to deprecation for SRM

Morris:
the only way of profiling is three documents

Steve:
assign writers to the documents?

any volunteers to write the profiles?

Morris:
Duane's document is a good starting point

after agreement somebody needs to do it.


slide 23:
point in transport question:
currently X.509 proxy
not talking about encoding of attributes itself

second way of doing this is SAML
SAML...