[OGSA-AUTHZ] Updated version of VOMS Specification

[Vincenzo Ciaschini]

Blair Dillaway wrote:
> 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.
> 
But the RFC recommends that only one should be used. Done.

> (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.
Right, done.
> 
> (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.
Unfortunately, that is the besr that ca be done for the moment, since it 
should continue to be included until the software out there has has a 
reasonable chance to change its implementation not to rely on it. 
Obviously, this come free if the official APIs are used.

> 
> 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.
> 
The intent of the sentence is to state that applications interested in 
reading the date should deal with the case that the field could be empty.



> (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.
> 
As said, it is name-specific, meaning that each attribute can choose its 
own way.

> Regards, Blair
Bye,
    Vincenzo

> 
> 
>> -----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
>> 
> 
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: VOMSACv7.doc
Type: application/msword
Size: 186880 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-authz-wg/attachments/20060511/eb83461d/attachment.doc