canonicalization for XACML instances being signed

[Anne Anderson <Anne.Anderson@Sun.com>]

I am trying to wrap up the next revision of the XACML DSig
Profile.  To bring everyone up to date, our profile says "follow
the SAML DSig guidelines"
(http://www.oasis-open.org/committees/security/docs/draft-sstc-xmlsig-guidelines-03.pdf),
and then adds only instructions specific to the XACML payload,
such as how to handle <PolicyIdReference> and
<PolicySetIdReference>.

The hard part is dealing with canonicalization.  SAML's DSig
Profile seems underspecified here, and not just for use with
XACML.  The Exclusive Canonicalization it recommends does not
create canonical forms of XML Schema primitive datatypes (such as
"...#boolean" becoming either "true/false" or "1/0") and does not
deal with things like schema-specified default values.

Joe Reagle suggested I look at Schema Centric XML
Canonicalization
(http://uddi.org/pubs/SchemaCentricCanonicalization.htm).  This
seems to handle all sorts of issues such as this, but I don't
feel qualified to evaluate it.  Does anyone have expertise in
this area?  Does anyone know how widely it has been implemented?

Related question: do we actually need to deal with canonicalized
XACML schema instances?  If the instances are always signed and
signature-verified in their unparsed text/octetstring form, then
there is no need for canonicalization.  Canonicalization would
come into play if people will be taking parsed XACML schema
instances out of the SAML envelope and re-encoding them for
repackaging in some other envelope, while retaining the original
signature.  Will this be happening?  For example, will an XACML
Response be removed from its SAML DecisionStatement or SAML
Assertion and put into some other envelope for retransmission?

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