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

[Michael McIntosh <mikemci@us.ibm.com>]

Forwarded on behalf of Eve Maler of
the SSTC 

----- Forwarded by Michael
McIntosh/Watson/IBM on 03/31/2004 10:59 AM -----

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

03/31/2004 10:59 AM

To	Anne.Anderson@Sun.COM
cc	"'security-services@lists.oasis-open.org'" <security-services@lists.oasis-open.org>
Subject	Re: [security-services] Comments on Attributes in Draft 08        e-draft-03-diff

[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


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php.