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

["Eve L. Maler" <Eve.Maler@Sun.COM>]

[Mike McI., can you please forward to the XACML TC list?  Thanks.]

Hi Anne,

In the SAML F2F this week, we've just finished discussing the proposed 
SAML attribute statement/query changes, and we've made some (hopefully 
final) decisions in this area.  We wanted to feed this information back 
to you, and particularly ask if you can discuss one remaining issue with 
the XACML TC in your meeting tomorrow morning (and get back to us 
immediately afterwards if possible, since we're meeting through Thursday 
noonish Central Time).

Anne Anderson wrote:

> Some problems with the specification of Attributes in Draft 08:
> 
> 1. NameFormat [Required]
>      A URI reference representing the classification of
>      the attribute name for purposes of interpreting the name.
>      See Section 7.x for some URI references that MAY be used as
>      the value of the NameFormat attribute and their associated
>      descriptions and processing rules.  If no NameFormat value
>      is provided, the identifier
>      urn:oasis:names:tc:SAML:2.0:attname-format:unspecified (see
>      Section 7.x) is in effect.  Type="anyURI".
> 
>    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.

The NameFormat is just an identifying URI, and has no expressed 
connection to a schema; this concept is used throughout SAML (e.g., 
NameIdentifierFormat) and is not new here.  If you want to suggest any 
prose clarifications along these lines, I'd be grateful.

We discussed the problem of providing too many vague options in this 
area, and finally satisfied ourselves that keeping a required Name and 
offering an *optional* NameFormat with a default of "...unspecified" 
corresponds most closely to the behavior and wishes of most SAML users. 
  Using a NameFormat of "...uri" (or inventing your own) gives other 
populations the ability to specify more of the interpretation 
assumptions in-band.  We felt that this was the best compromise in 
service of both interop and the reality on the ground.  XACML folks 
would probably use "...uri".

> 2. Source [Optional]
>      The source location or database from which the attribute
>      came.  Interpretation of the source information is
>      application-specific.  Type="string".
> 
>    Comment:
>      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.

We decided to eliminate Source.  This was an attempt to provide a second 
field for those who prefer a two-part attribute name, the way we 
(roughly) used to have with AttributeName and AttributeNamespace, but we 
agreed that it was too loose to provide any interop usefulness to 
anyone.  For those who want that second name part, we provided the 
<anyAttribute> wildcard, about which more below.

> 3. Arbitrary attributes
>      This complex type uses an <xsd:anyAttribute> extension point
>      to allow for arbitrary XML attributes to be added to
>      <Attribute> constructs without the need for an explicit
>      schema extension.  This allows additional fields to be added
>      as needed to supply the context in which the attribute
>      should be understood.  SAML extensions MUST NOT add local
>      (non-namespace-qualified) XML attribuets to the
>      AttributeType complex type or to any element bound to this
>      type or a derivations of it; such attributes are reserved
>      for future maintenance and enhancement of SAML itself.
> 
>    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.

SAML has a number of explicit extensibility points, through which we try 
to govern the *forms* of extension while not (much) constraining what 
extenders do; the goal is to gain measures of both interop and 
flexibility.  The <anyAttribute> wildcard is one mechanism among many 
that we employ.  You may want to see our schema extensibility position 
paper for more thoughts on this subject.[1]

Today we agreed to add an <anyAttribute> wildcard to AttributeDesignator 
to allow for application-specific enhanced querying, as well as 
retaining <anyAttribute> on Attribute to allow for application-specific 
scoping etc.

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

As noted above, Name is nominally (ha) a unitary name field, and 
NameFormat simply explains how to interpret it; this is qualitatively 
different from the old AttributeName/AttributeNamespace pair, which was 
truly two-part.  The NameFormat field has two SAML-predefined values 
("...unspecified" and "...uri"), and anyone can define others.  Please 
let us know if this remains unclear; I'm hoping that our new Baseline 
Attributes document will help explicate.

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

On reflection, we would actually like to eliminate ValueType.  The 
theory is that, given the unconnectedness/skew of this notion to the 
xsi:type method of governing attribute values, plus the lack of 
expressed need by native SAML users for a URI-based typing mechanism, 
this is best done by the addition of a global attribute through 
<anyAttribute>; this puts the burden of semantic clarity on the definer.

So we are anticipating that the XACML profile of SAML may define one or 
more attributes here, most urgently something like an xacml:ValueType 
attribute; you would be free to prohibit any further extension.  Our new 
Baseline Attributes document would explain how to do this. (Note that 
you would be free to define such XACML extensions using XML Schema if 
you wished, though the <anyAttribute> formulation doesn't require it.)

We specifically were hoping for feedback on the acceptability of adding 
an XACML-specific ValueType attribute vs. having a SAML-native ValueType 
attribute.

Thanks!

	Eve

[1] 
http://www.oasis-open.org/committees/download.php/5227/sstc-maler-schema-extension-02-diff.pdf

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com