[OGSA-AUTHZ] Updated version of VOMS Specification (FINAL)

[Von Welch]

Vincenzo,

  One question, according to 4.1.1 the extension id is { voms 5 },  
but looking at the example in section 5, I don't actually see that  
extension used. What am I misunderstanding?

  One suggestion, the definition for the voms base oid is currently  
somewhat buried in section 3.4.1.1, I suggest pulling that out and  
making it more prominent.

Von

On May 31, 2006, at 8:18 AM, Vincenzo Ciaschini wrote:

> Here it is included what is in our intention the final version of  
> the document. There is only one change from the previous version.   
> The attribute Tags has become the extension Tags, and has been  
> moved to the corresponding section.
>
> The reason for this is that adding an atribute cause backwards  
> compatibility problems with some existing APIs to access the AC and  
> so, in the interest of backwards compatibility, the data has been  
> moved to an extension.
>
> Bye,
>    Vincenzo
>
> Vincenzo Ciaschini wrote:
>
>> 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
>>>>
>>>
>>>>
>
> <VOMSACv8.doc>