From GFD 182 (page 6) §3.4.1.2:
Groups are organized in a tree structure, meaning that a group may have subgroups, which in
turn may have subgroups, etc… The group name is then represented in the following way:
/<root group>/<subgroup>/…/<subgroup>
Where <root group> MUST be the name of the virtual organization.
Therefore, I believe the voms-api-java library should check whether this condition is held, when validating the AC.
From a quick inspection (checking v3.3.3), it seems that the o.i.v.a.i.DefaultVOMSValidationStrategy class makes no check on the VO name, which would allow the inconsistency where the AC's VO name does not match a FQAN's <root group>.
Please consider updating DefaultVOMSValidationStrategy by adding a test for this situation.
I have no strong opinion on how to handle situations where an FQAN's <root group> is not the VO name. One option would be to reject the complete AC, another option is to accept the AC but filter out any inconsistent FQANs. I would tend towards the latter, but (as mentioned), this isn't a strong opinion.
From GFD 182 (page 6) §3.4.1.2:
Therefore, I believe the voms-api-java library should check whether this condition is held, when validating the AC.
From a quick inspection (checking v3.3.3), it seems that the
o.i.v.a.i.DefaultVOMSValidationStrategyclass makes no check on the VO name, which would allow the inconsistency where the AC's VO name does not match a FQAN's<root group>.Please consider updating
DefaultVOMSValidationStrategyby adding a test for this situation.I have no strong opinion on how to handle situations where an FQAN's
<root group>is not the VO name. One option would be to reject the complete AC, another option is to accept the AC but filter out any inconsistent FQANs. I would tend towards the latter, but (as mentioned), this isn't a strong opinion.