[OGSA-AUTHZ] VOMS Primary Attribute

[Tim Freeman]

On Wed, 31 Jan 2007 17:08:37 +0100
Vincenzo Ciaschini <vincenzo.ciaschini at cnaf.infn.it> wrote:

> Hi David,
> 
> David Chadwick wrote:
> 
> > 
> > Valerio Venturi wrote:
> > 
> >>On Mon, 2007-01-29 at 20:10 +0000, David Chadwick wrote:
> >> 
> >>
> >>>>* VOMS profile Discussed on Oct 16 telecon - minutes on list Meaning
> >>>>of the primary type must be explicit rather than implicit (as 
> >>>>currently done via sequence) Awaiting response from VOMS group
> >>
> >>What we haven't understood so far is why an explicit primary attribute
> >>is needed rather then an implicit one and what needs an eventual change
> >>in VOMS AC format would address.
> > 
> > 
> > Hi Valerio
> > 
> > The OGSA Authz group is not saying that an explicit primary attribute is 
> > needed. It is saying that if you have a set of attributes, then they are 
> > all the same, and should be treated as all being the same, and you 
> > cannot imply something special for the first one in the list, since the 
> > order may not be maintained by intermediate processing nodes, or even by 
> > software modules within one system.
> Ahhhh....  I think that there is a misunderstanding here.  It is 
> certainly true that a single Attribute object may contain a SET OF 
> AttributeValue, thus creating the problem you just described.  However, 
> the VOMS attribute is defined as such, as you may also see in the profile:
> 
> name         : voms-attribute
> OID          : { voms 4 }
> syntax       : IetfAttrSyntax
> values       : Multiple not allowed
> 
> This means that only one value may be present in there.
> 
> The different FQAN are then encoded in that single value in a sequence.
> 
> Evaluating nodes are so required to keep the order to comply with ASN.1 
> decoding rules, thus eliminating the issue.
> 
> Ciao,
>     Vincenzo

Preserving sequences seems like a tenuous mechanism to flag an attribute value
when there are options available like flagging it explicitly.

"It would be nice" if the intermediary could translate those FQANs into other
representations than ASN.1, though, and not worry about order.  For example in
GT4.1, we'd like to throw the attributes one by one into a bag of attributes
about the client (the bag being contributed to by many attribute sources) --
David's "software modules within one system" point.  Another example is
converting the FQANs into multi-valued SAML attributes -- intermediary
processing example.

I'm not saying this is some hard design principle that "must" be ahered to,
ultimately if VOMS won't change then people will just need to continue adapting
to its inner workings if they want to preserve its primary attribute semantics.

Tim