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
>>The Globus Project - Argonne National Laboratory
>
>
--
Frank Siebenlist
The Globus Project - Argonne National Laboratory
