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] | [List Home]


Subject: SAML question on our attribute typing mechanism


At the SAML Focus Group meeting yesterday, Eve Maler took an
action item to ask me for the historical use cases that underlie
the XACML decision to use a URI-based type system.  This came up
as part of the discussion of Rebekah Lepro's attribute proposal,
which I've attached for more context.

I think the question being asked is: Why did we specify our data
types using an XML attribute of type "anyURI" in the Attribute
name and AttributeValue elements, rather than letting the values
have types defined via schemas?  For example, why use
    <AttributeValue DataType="X">xxxx</AttributeValue>
rather than
    <AttributeValue><X>xxx</X></AttributeValue

Very rough draft answer:

XACML allows a policy to use types defined by schemas.  For
example, "X" in the first example above could be an XML-schema
defined type, resulting in
    <AttributeValue DataType="X"><X>xxxx</X></AttributeValue>

But evaluation of a policy requires comparisons and operations on
data.  If the policy engine is to support standard functions for
doing these comparisons and operations, then standard data types
are required.  XACML, by supporting a rich set of standard data
types and associated functions, allows most policies to be
supported by standard policy engines, rather than by requiring
pluggable code for each new data type.

An alternative is to support XPath query operators, where the
arguments are XPath expressions that resolve to values of
primitive data types that the query operators understand.  XACML
did not want to require use of XPath, so did not want to force
this solution.  XACML does allow attributes to be specified using
XPath expressions as an option, and these expressions can be used
to extract primitive data elements from an Attribute whose data
type is defined via an XML schema-instance.

Can other members help me out here?

Anne
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

 > Discussion on draft-sstc-attribute-02.pdf (Rebecca Lepro):
 > 
 > http://www.oasis-open.org/apps/org/workgroup/security/download.php/4884
 > 
 > The original "attribute" work item has been broken down into subparts 
 > over time.  There have also been some anticipated interactions with 
 > other work items, such as W-2 (nameid).
 > 
 > In Section 2.1, what is meant?  Is this about stuffing multiple values 
 > into a single statement vs. providing them marked up separately? 
 > Currently, there's some ambiguity about how to do this; people can do it 
 > either way and we provide no guidance.  An extension schema (as 
 > mentioned in lines 47-48) ends up providing application-specific rules 
 > about this.
 > 
 > We think it would be sensible for SAML itself to be more prescriptive on 
 > this point.  We have a repeatable AttributeValue element now, but we 
 > don't yet say anything about when/how to use it.
 > 
 > There's also an issue, not mentioned here, about what to do with 
 > empty/null values.  We certainly don't want to get absence of values to 
 > be confused with empty-string values (though note that AttributeValue 
 > currently has a mixOccurs of 1).
 > 
 > Section 2.2 doesn't quite highlight the fact that implementors (mostly 
 > Prateek and Rob) have reported usage of AttributeNamespace for a 
 > scope-like purpose.  We'd like to be more prescriptive about how to do this.
 > 
 > AI: Rebecca to mention the AttributeNamespace usage in the next version 
 > of the paper.
 > 
 > Section 2.3 suggests that the attribute issuer be captured.  This would 
 > be in addition to the assertion issuer.  Rebecca isn't sure she supports 
 > this requirement anymore; she goes back and forth.  Bob Morgan sent a 
 > message recently in opposition to this requirement:
 > 
 > http://lists.oasis-open.org/archives/security-services/200401/msg00036.html
 > 
 > Scott notes that without a signature, indicating the attribute (vs. 
 > assertion) issuer is meaningless.
 > 
 > Because the solution proposal provides an easier way to set the 
 > attribute type, it pushes off the need for attribute issuer information 
 > a little bit.
 > 
 > Prateek's company doesn't have any use cases for 2.3, and it does add 
 > complexity.
 > 
 > The current NameIdentifier proposal could be used here.  How would we 
 > inform users of this option?  It would be non-normative.  We could 
 > publish a white paper, or the community that wants to supply attribute 
 > issuers (assuming it's not us) could publish a normative or 
 > non-normative document on this.  We're not sure who the interested 
 > communities even are.
 > 
 > Eve suggests that Rebecca decide if she'd like to yank this requirement, 
 > based on the non-enthusiastic reception on this focus call, and reissue 
 > for consideration of the whole TC.
 > 
 > Section 2.4 points to the need to express value type information on the 
 > Attribute element rather than the AttributeValue element.  XACML 
 > expresses type information in its own URI-based language, whereas SAML 
 > uses XSD mechanisms.  What's the right way to make XACML and SAML 
 > attributes talk to each other?
 > 
 > Scott suggests that we first have to talk about how to uniquely name 
 > attributes, which has an impact on the typing problem.  They are not 
 > distinct from each other.  This relates to the one-part vs. two-part 
 > naming discrepancy, but is broader than just the technical issue.  There 
 > are some philosophical mismatches between the two specs right now.
 > 
 > In XACML the attribute ID and the attribute datatype must match, and it 
 > doesn't support non-uniform multivalued attributes.  SAML ended up 
 > allowing this latter situation, but sort of by accident.
 > 
 > Eve wonders if we should move in a direction that more consistently 
 > adheres to the LDAP paradigm.  Scott believes that SAML is pretty 
 > consistent with the LDAP paradigm, in that it provides the datatype at 
 > the point where it directly applies.
 > 
 > The issue, then, is whether SAML thinks it should move in a more 
 > XACML-compatible direction; this applies to both 2.4 and, in part, to 2.5.
 > 
 > AI: Eve to ask Anne Anderson for the historical use cases that underlie 
 > the XACML decision to use a URI-based type system.
 > 
 > Is it interesting/feasible to allow for both type representations? 
 > Rebecca has left the original mechanism in her solution proposal 
 > precisely to preserve backwards compatibility.
 > 
 > Scott doesn't really object to adding a datatype attribute to the 
 > Attribute element with a URI value, but would we reference the XACML 
 > specification for the universe of URIs to use there?  Eve mentions that 
 > XSD datatypes can be referenced by URI (though it pretty much requires 
 > setting ID attributes on <xs:complexType> and so on -- we might want to 
 > add IDs to our schemas for this purpose), and RDF types can also be 
 > referenced by URI.
 > 
 > The solution proposal indeed already proposes an addition of a 
 > URI-containing attribute, so it doesn't need to be modified on this 
 > score.  If we ultimately accept the proposal, we'd want to 
 > non-normatively reference various sources of datatype-related URIs.
 > 
 > Section 2.5 discusses the compatibility issue head-on.
 > 
 > Scott notes that reusing AttributeNamespace for datatyping at the 
 > Attribute level might clash with others' existing reuse of 
 > AttributeNamespace for scoping.  Rebecca would like to hear more 
 > comments about attribute identity.



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