Moreno:
In this meeting the security discussion should be finalized to be able to concentrate on writing the document and 
discuss BES and JSDL.
The goal is to tune the existing standards but not completely redesign them.


ad 1) Review of actions/task

no deviations from plan


ad 2) Finalization of the discussion on the security profile(s). In 
particular, should be define multiple security profiles or a single one? 
In either case we must define a schedule and assign tasks for actually 
writing the profile.

Moreno:
It turns out that agreeing on a single security document is not possible due to different models.
-> consider to have at least two documents

Morris:
Just use proxies for delegation; define what works together with what -- plumbing.
eplxanation of two slides he prepared (http://forge.gridforum.org/sf/docman/do/listDocuments/projects.pgi-wg/docman.root
.input_documents.iirm)
-  IIRM building blocks
     need the plumbings well defined
     not only referring to BES (conputing) but also storage
     id based authorization is not the only way
-  IIRM key elements
     core building blocks horizontal -> OGSA-BES not a perfect standard for interoperability
     we should have more vertical plumbings (more than three) perhaps
problems with one specification
plumbing3 -> input for pgi (authentication, X.509 proxy certificates)
SAML assertions not only for BES
other refinements: really nail down the attributes in semantics

HPC oriented view now

OGF secure addressing
only in GENESIS-II middleware
check with each of the middleware providers the adoption of epr

Moreno:
easy enough to implement secure addressing; simple if only in epr (string) to say which profile to use
real scenario: query GLUE nad get answer: epr
SRM, BES web service interface

CREAM has legacy interface -> add PGI compliant interface and make old interface coexisting with PGI
new users who use eprs can us PGI

ARC:
comments on epr, OGF secure addressing
profile does not say how to use
which client?
could be part of PGI profile to say how to use with BES
real use case:
clients fetch GLUE info -> requires looking into epr.
Which kind of security system to take?

Moreno:
client queries GLUE info -> gets list of services, eprs
How can the info be queried in CREAM?
always need X.509 certificate and proper security settings to be able to query. => circle!!!
client has to be aware of security requirements of service
identified not by simple URI but by full epr

should have both: GLUE and OGF secure addressing
where to read about?
draft version of GLUE spec

XML model in egee and ARC:
info in LDAP database; query anonymously; LDAP standard query; not web service; was proposed by Globus; pretty fast, 
scalable, lightwight -> easy to run
contact info system (black box)

GLUE elements inside BES
-> GLUE sub elements

directory service to find a service

Laurence:
directory service not so out of date
epr describes security settings
information model of endpoint

Morris will circulate document for others to comment




3) (if there is enough time left) Discussion about the proposal for the 
new JobPurge BES operation: http://forge.ogf.org/sf/go/doc15414?nav=1

4) AOB