[OGSA-AUTHZ] Updated version of VOMS Specification (FINAL)
Vincenzo Ciaschini
vincenzo.ciaschini at cnaf.infn.it
Wed May 31 08:18:30 CDT 2006
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
>>>
>>
>>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VOMSACv8.doc
Type: application/msword
Size: 184320 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-authz-wg/attachments/20060531/97a97ac1/attachment.doc
More information about the ogsa-authz-wg
mailing list