[OGSA-AUTHZ] Updated version of VOMS Specification

[Blair Dillaway]

Vincenzo,

In reading this draft I've found a few places I believe would benefit from some additional clarification.

(1) 3.1.1 - "As a consequence of this, in VOMS ACs the only admissible choice for the field is the baseCertificateID."

You might re-write this to say the holder field MUST include the baseCertificateID field and omit the entityName and objectDigestInfo fields. The syntax defines a sequence of 3 optional fields, not a choice.

(2) 3.4.1.2 - "Where <root group> is by convention the name of the virtual organization."

The document seems to imply this is a required encoding for interoperability purposes. If so, its not just a convention. You should clarify if this is a MUST, SHOULD, or RECOMMENDED encoding.

(3) 3.4.1.2 - "Future compatibility issue: It is possible that in the future a /Role=NULL component may be omitted in its entirety.  The same goes for a /Capability=NULL part.  Conforming applications SHOULD be prepared to handle these cases."

The previous paragraph states "The /Capability=<capability name> part is deprecated....". If so, I assume conforming implementations SHOULD always omit the /Capability part whether or not its null. Having it be deprecated and noting it may disappear in the future seem to be in conflict.

Also the statement that /Role=NULL *may* be omitted in the future seems to be in conflict with the examples in 3.4.1.3. The compact format shown does omit Role=NULL. If this is allowed, then the 'in the future' qualification should be removed. It should be stated if the compact format is recommended, required, or simply a supported encoding option.

(4) 3.4.2.2 - "A name-specific syntax that encodes multiple values in a single pair is also allowed."

Examples of a single value and multiple value encoding would be helpful here. The syntax in 3.4.2.1 indicates a Tag includes only a single name, value, and qualifier field. I assume how multiple values are encoded into the value field should be specified for interop purposes.

Regards,
Blair

> -----Original Message-----
> From: owner-ogsa-authz at ggf.org
> [mailto:owner-ogsa-authz at ggf.org] On Behalf Of Vincenzo Ciaschini
> Sent: Friday, April 28, 2006 6:34 AM
> To: ogsa Authz
> Subject: [OGSA-AUTHZ] Updated version of VOMS Specification
>
> Hi to All,
>
>     This is the updated document about VOMS specification I
> promised yesterday.
>
>     Apart from a few minor language clarifications, the main
> changes are in the following sections:
>
> 3.4.1  clarifications about the syntax of FQANs.
> 3.4.2  rewritten, with a (slight) change in format.
> 3.5.1  explanation rewritten.  The previous explanation was the exact
>         opposite of the truth. OOPS!
>
> Also, the AC example in section5 has been substituted with a
> more complete one.
>
> Bye,
>     Vincenzo
>
>