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

[Vincenzo Ciaschini]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: VOMSACv9.doc
Type: application/msword
Size: 209408 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-authz-wg/attachments/20060908/3a159948/attachment-0001.doc