[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] canonicalization for XACML instances being signed
Hi Anne, Anne Anderson wrote: > XACML does not currently define semantics for delegation > operations. For example, it is possible to express the following > two policies: > > Policy 1: entity A says entity B can assign rights Y and Z > Policy 2: entity B says entity C can have right Y > > But there are no semantics defined for verifying that the linkage > is correct. right, and I understood that for the delegation of rights as in an authorization rule or decision, but until David's email I didn't make the link to the delegation of attribute assertions... which is similar but may require a somewhat different processing (?). > This is one of the big differences between a digital > rights management language (which must use simple conditions in > order to be able to define semantics for all linkages) and an > access control language such as XACML (which can express complex > conditions over multiple subjects and resources). > > It would be easy to define an evaluation semantics for simple > delegation such as that above, however. We just haven't done it > yet. Easy is good ;-) Regards, Frank. > On 29 August, Frank Siebenlist writes: Re: [xacml] canonicalization for XACML instances being signed > > From: Frank Siebenlist <franks@mcs.anl.gov> > > To: "D.W.Chadwick" <D.W.Chadwick@salford.ac.uk> > > Subject: Re: [xacml] canonicalization for XACML instances being signed > > Date: Fri, 29 Aug 2003 17:22:01 -0700 > > > > 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 > > > > > > 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.php. > -- 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]