[voms-proc-wg] VOMSPROC WG session and strawman document

[Andrea Ceccanti]

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