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: 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...
>>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"
>>>and then adds only instructions specific to the XACML payload,
>>>such as how to handle <PolicyIdReference> and
>>>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
>>>(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?
>>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]