Hi, I attach notes extracted from various emails between Akos Frohner, Stephen Burke and myself. Please read them before continuing ... I trust you have now read them I find that the set of use cases and other arguments in "thoughts on authz" convinces me that we do need to be able to specify the authz information explicitly. However I do think that in order to ensure that the API remains easy to use we should continue to allow the authz information to be taken from the security context - with the caveat that this may actually not make much sense with some authz schemes. If this is accepted then the only problem is how to represent this information. The draft spec says that you match against a "VO" however it says that the "VO" may in fact be any string and anticipates that a common use will be with the IN operator for eaxmple VO in 'CMS, 'ATLAS'). So I suggest simply changing the name of the field from VO to Authz and "VO Filter" to "Authz Filter". To map it onto the GLUE tree structure we could take all concatenations (perhaps separated by a "." of the name fields in the hierarchy of "User Domain" names. In practice I think it will be somewhat implementation dependent because different grids will use these fields in different ways. This set of concatenations would be the set of valid Authz values. It will not guarantee that you can use the service but can we do better and still keep it simple? Steve