MHonArc v2.5.2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [xacml] Proposal of XML Access Control Use Case of XACML
Hi Simon
I think that the flat context is simpler and manageable.
I found a little difficulty in transforming SAML request into
Context particularly when the original data has some structure,
but that would be a minor issue.
For the XPath and namespace, you are right. I found an API
that receives namespace node in addition to the usual arguments.
Michiharu Kudo
IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
Simon Godik
<simon@godik.com> To: XACML TC <xacml@lists.oasis-open.org>
cc:
2002/07/26 05:23 Subject: Re: [xacml] Proposal of XML Access Control Use Case of XACML
Please respond to
Simon Godik
Hi Michiharu,
What do you think if in addition to resource attributes that you construct
out of resource uri we
make:
<Attribute AttributeId="urn:oasis:names:tc:identifiers:resource-uri">
<Attribute AttributeId="urn:oasis:names:tc:identifiers:resource-syntax">
(aka Format)
<Attribute AttributeId="urn:oasis:names:tc:identifiers:resource-scope">
Then we can drop <ResourceSpecifier> element altogether. I know that you
proposed flat
context before and it will make it 'flatter'. There is another advantage to
doing this. If only elements
that we have to address out of the policy are attributes in the context,
non-xpath AttributeDesignator
could be made simple (I posted a note on that recently)
xpath and namespaces.
on lines 433-434 of your proposal you say that pep and pdp must share
namespace-uri and corresponding
prefix. Namespace-uri must be shared. For namespace prefix there is an easy
work around:
<Attribute xmlns:c="urn:oasis:xacml-context" xmlns:a="http:myNS">
/c:Request/c:Resource/c:ResourceContent/a:employee/a:phone
</Attribute>
Simon Godik