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

MHonArc v2.5.0b2 -->
















xacml message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








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




From: Michael McIntosh <>
To: <>
Date: Wed, 31 Mar 2004 11:03:41 -0600




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"
<> 
03/31/2004 10:59 AM




To



cc
"''"
<>


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.














[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]