(1) OGF PGI Security model (see emails) and 'plumbing' approach
clarify where we want to go
boundary conditions
look on drafts
review Morris slides
GSI connection
Aleks:
not forced to use
GSI stands for what Globus implemented
Morris:
We have to support other connection mechanisms
Aleks:
something what is used by SRM
Morris:
numerous gftp, SRM interfaces
GSI connection because of incompatibility
Andrew:
- eps compatible in a Grid island?
- you have to use PGI SSL
we don't have to connect to other service
Aleks:
legacy services
Andrew:
no
Morris:
changing a number of implementations?
Andrew:
maybe easier to create a new one instead of changing
Morris:
Problem: no development power in PGI/GIN
Andrew:
ARC/gLite/NAREGI interop now?
Morris:
modificatioins, tunings
Andrew:
add another thing?
Morris:
use only standards used in production
--> tuning standards
most significant problem: security

profile with sub profiles
pgi compliant ep interacting with another pgi compliant ep
pairwise
no precise understanding
not to have the prefect security implemented in every Grid infrastructure
in many infrastructures: lack of resources to implement
maybe only 3, 4 different simple options in plumbings
Moreno:
what wi are willing / able:
implement interface on exec. services
pgi interface on top 
more than ready to do in gLitesecurity serious problem:
in gLite very hard to switch from proxies to SAML assertions because "security is everywhere"
common sec. infrastr. in gLite is very tight
at the moment it is difficult to have big changes in current implmenetations
Morris:
maybe diff. deployments of middlewares
some people have otherpolicies
choosing which plumbing wanted

GLUE entities
other services in epr
Duane:
no other info service than epr needed
well defined OASIS description of security
policy to put in epr

GSI proxy, GSI connection to the server

Morris:
GLUE capability

Duane:
authentication question
UNICORE authentication?
sign message level
WS-security slides?
no slides for message level
sender is authirzed
his public key is signed
chain!
normal TLS

SAML assertion
Morris:
do another hop
Duane:
talking about message, attibute?
Morris:
whole UNICORE frameworkt based on signed certificates
Duane:
holder of key approach
--> should be profiled
Morrsi:
not to deep in details
Etienne:
different capabilities
each of the services pulishes capability according to GLUE model
clients request db
Aleks:
will need some initial info to connect to db
Etienne:
clearly written: GLUE db
--> bootstrap
main thing is info service
Andrew:
focus on TLS, GSI
not focus o requirements of ep
Morris:
requirements in slides
everybody agree: GSI connection?
Aleks:
no, not properly standardized and documented
Duane:
no
Aleks:
try to drop GSI
Balazs:
why not address SRM?
Moris:
not idea to do the sams as OGSA
unhappy with GSI connection
backbone in transport

drop GSI?
Aleks:
Yes
crossgrid
intermediate services
Morrsi:
ByteIO in UNICORE
Moreno:
hoping the services will rely on gridftp in data transfer
Morris:
UNICORE could get rid of GSI
Aleks:
get rid of GSI in W connection?
Etienne:
we need delegation for data transfer

voting:
gLite
ARC
UNICORE
GENESIS
agreed to drp GSI

Mineo:
NAREGI needs GSI
no budget to move to another securita model
Morris:
very less money for development
Duane:
could find out what they need
Morris:
resource side maybe possible
Duane:
transport layer?
Morris:
in security every little component has to be touched
change port type
#provide new versions of clients
need authentication, authorization nailed down
Duane:
survey on security - not profiling
Morris:
what is this sec. setup?

what are the building blocks in communication?
if we do the interoperation thing, we have to focus on production, users
top down approach

at least we agree on different...