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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

Subject: [xacml] SAML Attribute Representation

I promised the Policy Model Group I would post pointers to the current SAML
Attribute Syntax and the debate over attribute scope vs, namespaces.

The current core spec is here:


and here:


depending on which format you prefer.

Attributes are discussed in section 1.6.

I just noticed that apparently OASIS only keeps public archives for the
current month and some of the discussion was in late September.  However the
key message is attached.

To summarize, the discussion that followed, it was pointed out that scope
can be provided in the schema

An aspect of authorization attributes that we ran into fairly early on
in Shibboleth was the concept of "scope", independent of the asserting
party or the value of the attribute.

For example, eduPerson defines an LDAP attribute called Affiliation to
capture, in a simple enumeration, a set of common university groups
(faculty, staff, student, etc.) that may be useful for document access
control lists. The values are simple strings ("faculty") that don't
communicate the scope of the relationship (ie. faculty *at* the Ohio
State University).

Clearly, to create a useful access control entry, both notions must be
captured by the resource manager. Our solution in Shibboleth was to make
scope a first-order data element to be communicated in our attribute
assertions. We also use the scope information to enforce attribute
acceptance policies which define what information a particular attribute
authority is allowed to assert to a destination site.

This is something that isn't currently representable in the SAML schema,
except as part of an attribute's value. The disadvantages to that
approach include that the scope value would often be redundantly
included for many attributes in an assertion, and it complicates even
simple attribute values by adding an additional piece of information
that must be captured.

Note that this is also totally distinct from the attribute's namespace,
in XML terms, which isn't about value scope but about name scope,
analagous to the eduPerson schema, rather than any particular school
using it.

We would propose an optional string attribute or element in an attribute
assertion that would define a default scope for the assertion,
overridable on a per attribute basis. At the least, being able to
specify it explicitly rather than inside the attribute values would be
an improvement.

  Scott Cantor               So long, and thanks for all the fish.
  cantor.2@osu.edu                  -- Douglas Adams, 1952-2001
  Office of Info Tech        PGP KeyID   F22E 64BB 7D0D 0907 837E
  The Ohio State Univ        0x779BE2CE  6137 D0BE 1EFA 779B E2CE

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

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

Powered by eList eXpress LLC