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

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

>      Is source a "database type" or a specific database
>      repository location?  If it is a repository location, say so
>      and make the type "anyURI", saying it SHOULD be a URL.
>      Also, if Source remains of type "string", there is the
>      possibility of name collisions.

It's definitely not (necessarily) a location, and there absolutely would be
collisions. It's not going to be unique across authorities, but I don't
think it has to be. (Of course, I don't expect to be using it either, so I
won't guess anything else about it.)

> 3. Arbitrary attributes
>    Comment:
>      The addition of facilities such as this guarantees
>      non-interoperability and makes it impossible to specify
>      standard mappings to other Attribute formats.  It is likely
>      to be mis-used, and common mis-uses then become defacto
>      standards that everyone has to work around.  Define any
>      number of specific, optional attributes instead, but make
>      sure each has a VERY clear semantic.

Not having wildcards is much worse than having them, IMHO. Dealing with
derived types that people will create in order to add their own attributes
is much, much worse for implementers. By design, any such attributes are
optional, in every sense. If your profile makes anything it defines
mandatory, that's a conscious choice *not* to interoperate. Since so few
people validate, they'll just end up doing this sort of thing anyway, this
just gives those of us that are validating some hope we can still understand

> 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

>      If not, at least define ONE scheme for
>      the NameFormat URI (such as "urn:") so that NameFormat and
>      Name can be concatenated using a single known separator
>      character (such as ":").  This will make mapping much easier
>      for systems that require unique identifiers for Attributes.
>      Even better would be to specify one unique name combining
>      Name and NameFormat.

I think it's the case now that in effect, any NameFormat/Name pair is
unique, since NameFormat is a URI. This was potentially true before in 1.x,
but because AttributeNamespace wasn't always viewed as part of the "name" of
the attribute, that was undermined. Now it's clear, since NameFormat is
quite obviously an aspect of the name and not of anything else. And we do
have a Format URI that says the Name is a URI.

> 5. ValueType
>    Comment: Reconsider making this "required" instead of
>      "optional".  Other standards groups have discovered that a
>      data type is necessary in the Attribute metadata in order to
>      handle type checking.  Having it be optional means only
>      certain Attributes can be handled easily by systems that
>      require type checking.

I continue to disagree, because whether something is necessary in attribute
metadata has nothing to do with whether it's necessary in a SAML assertion.
We're making it possible to carry this information in the assertion, but I
would not want to be forced to do it.

As I see it, data type should never be needed in-band except in a world
where an attribute is of type "variant". I'm not dismissing that case, but I
don't think it's the common one.

-- Scott

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