OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [security-services] Comments on Attributes in Draft 08e-draft-03-diff


> From: Scott Cantor [mailto:cantor.2@osu.edu] 
> > From: Anne Anderson
...
> >    Comment: If NameFormat is intended to map to a schema
> >      specification (or surrogate) in which the name is defined,
> >      please say so.  "A URI reference representing the
> >      classification of the attribute name for purposes of
> >      interpreting the name" could mean as many things to as many
> >      people as "NameQualifier" and "NameSpace" did.
> 
> I think NameFormat is intended to map to a syntax and 
> semantic for how the name identifies the attribute (just as 
> NameIdentifier Format does). The one defined value (so far) 
> says that the name is a URI, which means that the name alone 
> identifies the attribute in the abstract sense. 
> AttributeNamespace could have meant that, but some people 
> felt it meant something different.

NameFormat doesn't classify the *attribute*, it classifies the *attribute name*. I personally feel that this is serious over-engineering, because none of my use cases involve a *run-time* decision based on whether a specific assertion contains an attribute name that is specifically a URI or an OID or whatever; if the attribute name format is significant, I expect to get that information from a profile rather than at run time. YMMV.

> ...
> > 4. Name and NameFormat
> >    Comment: will these ever be used separately?  Does anyone ever
> >      want "all instances of the 'gorp' Attribute", regardless of
> >      the NameFormat, or "all instances of Attributes with
> >      NameFormat 'urn:oasis:tc:xacml:', regardless of the
> >      Attribute's Name.
> 
> My position on this has always been that this is silly, and 
> we should just use URIs for names, but that's not the 
> consensus opinion, so I think this is a step in the right 
> direction to at least clarify what AttributeNamespace is for.

While I agree with Scott, it's seems clear that others don't, since XACML already has URIs for names and they have determined that they still need the additional metadata.

 - irving -


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]