FW: [xacml] Notes from XACML Focus Group on SAML/XACML Attributes

[Rebekah Metz <rlepro@arc.nasa.gov>]

Notes posted from the XACML Focus call last Thursday to the XACML list.

Rebekah
------ Forwarded Message
From: Anne Anderson <Anne.Anderson@Sun.COM>
Reply-To: Anne.Anderson@Sun.COM
Date: Tue, 20 Jan 2004 11:55:41 -0500
To: XACML TC <xacml@lists.oasis-open.org>
Subject: [xacml] Notes from XACML Focus Group on SAML/XACML Attributes

My notes from the joint SSTC/XACML Focus Group to discuss the
convergence of SAML and XACML Attributes are attached.

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


Minutes of XACML Focus Group
15 January 2004
10am-11:40 EST

ATTENDEES:
 Anne Anderson    (XACML)
 Von Welch        (SAML)
 Polar Humenn     (XACML)
 Rebekah Lepro    (XACML/SAML)
 Simon Godik      (XACML)
 Mike McIntosh    (XACML/SAML)
 Frank Siebenlist (XACML/SAML)
 Michiharu Kudo   (XACML)
 Scott Cantor     (SAML)
 Paula Austel     (SAML)
 Bob Morgan       (SAML)

AGENDA: Convergence SAML and XACML attributes

1. Summarize issue

[Rebekah] Congruence between XACML and SAML representations of attributes
a. Concept of attr identity: SAML has two components, XACML has
   one.
b. Explicit datatype in XACML; XSD datatype in SAML
c. Concept of attribute issuer

Rebekah presented draft solution at SAML Focus Group.

[Scott] Unique def of attribute regardless of name should imply
the datatype.  Datatyping issue per se is not predominant; real
issue is automating mapping of SAML to XACML attributes.

2. Attribute issuer

[Rebekah] XACML is at Attribute level; SAML is at Assertion
level, and Assertion may contain may Attributes.  How is binding
of issuer to Attribute related to security; what are
security-related assumptions?  What does this imply about mapping
between SAML and XACML.  Relationship between Issuer and
Assertion signer.

When SAML Issuer does not match Signer.  What does that imply?
How does XACML Context Handler deal with this consistent with
security/trust assumptions.

[Anne] Signer may legitimately not match Issuer: Signer may
translate attributes from another format, and retain the other
format's Issuer.

[Scott] Open to interpretation.  SAML intended that they should
match.

[Bob] SAML assumed Issuer and Signer should be same.  Relying
party should check that they are consistent.  Proxy relationship,
as Anne suggested, might be OK.  Like SASL authorization ID.

[Anne] What does it mean if Signer and Issuer do not match?
Signer is asserting that it trusts the binding of Issuer and
Attribute.

[Bob] SAML does not define case where identity information in the
signature does not match stated Issuer in the Assertion.

[Rebekah] Had discussion with Scott on this.  Proposed insertion
text into SAML 2.0: "signature id should match Issuer id."

[Scott] Not necessarily accurate to say signer and issuer are
same, but association between the two where different is not
defined in SAML.

[Frank] SAML assertion binds something to a name.  SAML runtime
may not know what the something is.  That something may include
and "issuer", so it is up to the relying party to understand the
semantics of this.

[Bob] SAML can't define what "same" means, since digital
signature is so vague; but could say must effective identity
associated with the assertion is the issuer.

[Anne] XACML will assume Issuer of Assertion is Issuer of
Attribute.  Trust in the Assertion is a separate issue.
Concerned about need to support translation from one Assertion
format to SAML.

[Frank] Issue of who is trusted to sign a particular Assertion is
outside the scope of SAML.  If Signer is different from Issuer,
then interpretation is outside the scope of SAML.

[Anne] SAML should not say anything about the the mapping of
signer and issuer.  Match requirements are up to the relying
party.

[Scott] SAML implementations will do the matching in some
particular way, and they will do it the simple way.

[Frank] SAML implementation should just verify the signature,
then pass the Assertion as a "blob" (which just happens to
include an Issuer) to the relying party.

[Anne] DSig can include identity information needed to verify the
signature.  Why is a requirement being pushed onto SAML to
provide the identity information?  DSig can include just a name,
and does not have to include a particular certificate.  SAML
should state explicitly that Issuer and Signer do NOT have to
match; signatures used with SAML Assertions should contain all
information needed to verify the signature.  Let relying parties
impose additional match requirements, not SAML implementation.

[Scott] It is the Issuer that is making the claim about the
binding of attribute to attribute subject.  That is the basic
SAML concept.

[Frank] In local namespaces, Issuer becomes part of the value.
I.e. if Frank issues attribute with value "blue", then it is
Frank's definition of "blue".  Issuer becomes part of the scope.

[Bob] Organization is context for an attribute value.  Avoid
overloading issuer.  "x == blue" should be defined so that "x"
always has one meaning, and values for "x" such as "blue" have
one meaning.

[Frank] Two issuers might use "x" to mean different things.

[Bob] Should not depend on binding issuer to attribute id;
attribute ids should be globally unique and defined if that is
the semantic.

[Scott] What makes the issuer name unique, or globally unique?
If can make issuer name unique, why not make attribute id unique?

[Frank] Path validation of issuer name identity is done outside
of SAML, such as via X509 certificate path validation.

[Bob] Both Frank and Scott/Bob views may be valid in different
use environments.  Affects whether add "scope" feature to
attribute feature.  Frank may not need, if scope is associated
with issuer.  Scott/Bob may not need because require attribute id
to be unique.  Bob believes there is utility to "scope" feature
in yet other environments.

[Frank] Unable to provide unique meaning of an attribute id
without associating it with the issuer name and the path
validation that validates the issuer name.  Issuer name could be
a public key, and issuer can prove possession of the key.

[Rebekah and Frank need to be out or in and out.]

3. Mapping SAML Issuer to XACML Issuer

[Anne] XACML should associate SAML Attribute Assertion Issuer
with XACML Attribute.

[Scott] Yeah.  My understanding of way it worked in XACML means
SAML can continue to do same.  If SAML added Issuer to each SAML
Attribute, it does not clarify semantics and adds inconsistency.

[Rebekah] When constructing XACML Request Context, PDP assumes
that mapping of issuers to attributes has been done within same
trust computing base, so PDP trusts the Context Handler to do
that mapping.

[Anne] SAML semantic is that "Issuer of Attribute Assertion is
Issuer of each Attribute in the Assertion."  [General agreement]

4. Issuer datatype

[Scott] If SAML makes Issuer a richer data structure, will XACML
incorporate it?

[Anne] Yes (assuming richer data structure has acceptable syntax
and semantics).

AI: Scott send proposal richer name identifier data structure to
XACML list.  This new element would be used for both Subject and
Issuer.

5. Attribute Identity

[Scott] Attributes have unique (within interoperable SAML
deployment) names.  Name of attribute implies information about
its value, its type, the domain of its values, etc.

[Anne] for XACML's purposes, functions need to be applied to
attribute values, so explicit data type is needed for type
checking.

[Scott] SAML does not require presumption about attributes having
unique names, identity, datatyping.  Disadvantages of introducing
two-part names outweigh advantages.  No clear interpretations put
on those two parts.

[Anne] Certainly makes XACML use of SAML attribute harder!

[Scott] We're trying to collect common practice, then can have
productive discussion.  A lot of resistance to one-part names in
the past.

Some interest in discussing "scoping" within SAML: "source" of
the attribute.

[Bob] "Domain of interpretation".  E.g. "phone number", with
different domains: "work", "home", etc.  LDAP directory practice
is consistent with this.  So in favor of two-part names.

[Scott] Name and namespace can be the two parts of the name.

[Bob] This makes comparisons of things much harder to do.

[Anne] Mixing in datatype.  E.g. a phone number can be treated as
having one datatype.  Work-phone is of type "phone number", as is
"home-phone".  What are boundaries between data-type, attribute
id, scope?

[Scott] Does attribute namespace still have a purpose if there
are two-part names?

[Anne] SAML group should be very aware of the relying parties.
Using two-part names makes XACML policies much more complex.

[Scott] Phone number value should contain the "scope".

[Anne] XACML has clear boundary between "datatype" + value and
attribute id + scope: each datatype must have a set of functions
associated with it.  Putting scope into the value makes it harder
to define functions on those values.

[Scott] So long as interoperable way to map between XACML and
SAML, then no problem.

[Frank] where is this discussion within SAML?

[Scott] early.  Call for reactions to proposals, information
about what deployments are actually doing.

[Frank] what is the type of the "scope"?  String?

[Scott] Currently just two strings.

[Anne] If names are URIs, it is easy to define "tail" function to
extract the leaf portion of the name.

[Frank] So much going on in SAML group, it is hard to track ones
relevant to XACML.

[Scott] Rebekah's proposal has pulled together a number of these
threads.

AI: Anne to send out notes to meeting attendees, who should send
back corrections.  Anne will then send out amended notes, which
can be distributed to SSTC and XACML TC lists.


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/xacml/members/leave_workgroup.p
hp.

------ End of Forwarded Message