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

[Mary Thompson]

Vincenzo,
    I uploaded the version that was attached to your email to the 
GridForge page for OGSA-AuthZ-wg 
http://forge.gridforum.org/sf/go/projects.ogsa-authz/docman.root.attributes

Mary

Vincenzo Ciaschini wrote:
> Von Welch wrote:
> 
>>
>> Vincenzo,
> Hi Von,
> 
>>
>>  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?
> No, you are right.  What happened is that when I cut-and-pasted the AC 
> dump, I mistakenly deleted that line.  This is fixed now.
>>
>>  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.
> Agreed.  It is now In section 3, right after the AC definition.
> 
> Mary, since we consider the document final, can you upload it on the 
> ogsa-authz page along the other documents for public access?  We don't 
> seem to have access to do it ourselves.
> 
> Ciao,
>    Vincenzo
> 
>>
>> 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>
>>
>>
> 
> ------------------------------------------------------------------------
> 
> --
>   ogsa-authz-wg mailing list
>   ogsa-authz-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-authz-wg