The problem with an information model is that we can end up describing everything. The aim of Glue within OGF is to try and bring some of the other specifications together and not define so much by ourselves. For example, JSDL should describe the job and Glue should reflect this so that the job can be matched. The group defining JSDL should worry about the matchmaking should be worked out jointly between the JSDL group and Glue, but JSDL should be the definition which Glue reflects and likewise for the Authorization.
We need to narrow our focus or we will end up "boiling the ocean" which has happened to many other Groups and the definition will take forever.
From what I can see on the use of DENY tags within EGEE, this is a big hack to work around a implementation problem in the glite middleware and as such should not dictate what is done in Glue. We should just be able to published the ACLs in the FQAN format and that is it.
The reason for the DENY tags is the inconsistency with the simple matchmaking done by the WMS and the mapping of VOMS FQANs in a CE.
Laurence Field wrote: that's not completely true. The WMS was also extended to support the DENY option (it is just the matter of defining a new matching operator). The problem was that the LCMAPS component performed decision using a different logic than WMS (assuming order between rules). This should be solved in EGEE-3 as they have defined a number of recommendations which avoid the need for assuming ordering. We can leverage these recommendations and propose a basic syntax for policy rules. This is an important interoperability aspect and we have experience to do this, more than in GLUE 1.x.
If publishing only the FQANs does not work, it is not necessarily an information model problem but architectural issue that needs to be fixed and should be pushed back to those dealing the Authentication and Authorization. We need to take a more minimalistic approach do the schema definition and not try to fix other peoples problems. it could work, but it is not efficient.
Consider the Balazs use case: ATLAS has 100 groups. You want to state that 99 groups are authorized, but not /atlas/production/students. With just FQAN you have to list 99 groups, this is inefficient. The other way is to say /atlas/*:EXCEPT:/atlas/production/student or ALLOW: fqan:/atlas/* DENY: fqan:/atlas/production/student this is a simple set of rules (just allow/deny) which should be easy to map to underlyng middlewares. Cheers, Sergio