[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] canonicalization for XACML instances being signed
Hi David, Please let us help you to get rid of these flaky X.509 ACs with a combination of xacml attribute and policy assertions ;-) .. but you bring up an interesting point: how can I express the delegation of an attribute assertion? For example, if I want to assert you the right to use my "GoldMembership" for certain operation, how would I go about that within the xacml framework ? Regards, Frank. D.W.Chadwick wrote: > Frank > > X.509 ACs (partly) support this mechanism in one of the extension fields > (in much the same way the PKC trust chains are built up). So you can > calculate that a delegated credential is trusted, and that it is a > subset of the authorising credential, but without defining another > extension there is currently no way of signaling which part of a > credential can be delegated (its all or nothing) > > regards > > David > > > Frank Siebenlist wrote: > >>If I would delegate you some of my rights with the right to further delegate >>those onwards, like reading one of my files on a machine, and you would delegate >>those rights on to a third party, then in your authorization assertion for that >>third party, you will have to reference my original assertion somehow, either by >>complete inclusion of my original assertion or at least by inclusion of the >>digest value that I signed. >> >>My understanding of canonicalization is not good enough to state the >>implications of this... >> >>-Frank. >> >>Anne Anderson wrote: >> >> >>>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 >> >>-- >>Frank Siebenlist franks@mcs.anl.gov >>The Globus Project - Argonne National Laboratory > > -- Frank Siebenlist franks@mcs.anl.gov The Globus Project - Argonne National Laboratory
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]