On Wed, 31 Jan 2007 17:08:37 +0100 Vincenzo Ciaschini <vincenzo.ciaschini@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