Hi Paul, Il 12/10/12 15:49, Paul Millar ha scritto:
Hi all,
I haven't read the document yet (sorry, but it is on the list)
On 10/11/2012 06:08 PM, David Groep wrote: [...]
- Computing the intersection of a set of attributes coming from several ACs in the chain poses the problem of stating how the order of the attributes is computed when is different in the ACs. The document should address this, e.g. proposing that the the order of the AC result of the original user delegation is enforced.
Fully agree: the ordering section of the document is still missing, and we should think about what a user 'expects' in this case. Should a downstream service be able to 'select' a new primary FQAN by itself (i.e. on a service then selecting a new primary when writing data files)? But then the user may not 'know' this was to happen. I can see cases for either option, and the document should indeed be explicit in what is to be allowed.
Just a comment on what dCache does, which may be relevant. (I can't remember, have I already said this?)
We take the first FQAN as primary and all others as non-primary. If there are multiple ACs then (iirc) the first FQAN of the first AC is primary and all others (from all other ACs) are non-primary.
We do not preserve the order of FQANs, only that one is primary and the others are not. I like how you define primary FQAN (first fqan of first AC).
In a single AC FQANs are ordered by definition. voms-proxy-init provides an option to request a specific ordering from the server, applications could take advantage of that. In practice people just rely on the primary FQAN. However the point above is different, and is related to how the VOMS ACs are extracted and parsed from a chain. Currently VOMS attributes are extracted only from the VOMS extension found in the latest delegation in the chain. The proposal instead suggests AFAIU that all the valid ACs in the chain (not only the one in the latest delegation) are considered when parsing to ensure that the attributes returned are a subset of the attributes originally requested by the user from the VOMS server. In the end the application will always have an ordered list of ACs as result, that can be processed as you are describing now, but such list will be composed from several "levels" in the chain, not simply taken from the last delegation. VOMS APIs will do this composition work for you. However, this composition needs to be properly defined not only to ensure that the attributes returned are a subset of the ones originally requested but also to address the ordering (which may be different at different levels of the chain). The more natural approach to me is to keep the order as originally requested by the user. Other approaches are also possible and will be discussed here, I guess. Cheers, Andrea