Then I am definitely on-board Steven. I like the distinction you make between the fine-grained access (with a hierarchical resource e.g. medical record > fields in the record) and the fact that given access to a resource (doc or other) you want to mask a certain item in there.
It could for instance be an obligation to call the masking tool which determines whether a doc contains a credit card number and removes it.
On Fri, Sep 25, 2015 at 6:30 AM, Steven Legg <> wrote:
Hi David,
On 24/09/2015 6:48 PM, David Brossard wrote:
Hi Steven,
Interesting idea. I have also seen a similar trend in the insurance industry. The redaction is particularly useful in any industry where there is a strong standardization body which standardizes document structures (e.g. EHR, EMR...).
Using obligations is an OK approach but it hides away authorization semantics inside obligations which means you cannot easily audit your policies or even ask the simpler questions. Also it makes your PEP logic much thicker. And it poses the question of how you combine multiple obligations together.
Also you say that it would be faster to run a single request + obligations. I think an MDP would be equally efficient (the bulk of time spent is on the request-response not on evaluation). It makes enforcement easier.
You would typically ask:
* Can user Alice view medical record X... and field SSN... and field name... and field address...?
I wasn't thinking of such highly structured documents. This sort of thing is what
I would usually call fine-grained access control, where users are given rights to
perform specific actions on specific fields (columns, properties, attributes, ...)
with little or no regard for the contents of the fields.
For redaction, I was thinking about documents with only basic structure (chapters ->
sections -> paragraphs -> sentences -> words) where arbitrary passages of text
might carry classifications (top secret, etc) or other markings (Australian Eyes
Only, ANZUS Eyes Only) or might have annotations applied by tools that are looking
for certain kinds of sensitive information in the text. Individual words might
need to be redacted but processing an authorization request for every single word
would be time consuming.
Regards,
Steven
To which the PDP would reply Permit, Permit, Deny...
It makes the PEP easy to implement: all you have to do is enforce a Permit or Deny. It also means you probably want to integrate with a PEP capable of processing the type of document we are dealing with. If it is an XML document, then an API / XML gateway would be a great PEP.
Thoughts?
David
On Thu, Sep 24, 2015 at 8:00 AM, Steven Legg < <mailto:>> wrote:
On the last TC conference call Hal mentioned using multiple authorization requests
to redact a document. Basically asking for each discrete piece of the document
whether it is visible. This is the obvious way to do it but it is also expensive,
even using the Multiple Decision and Hierarchical Resource profiles.
The redaction solution I sketched out was the result of looking for a faster way
to do redaction. One request determines whether access to the document is permitted
and simultaneously returns the instructions for redacting the document, as
obligations, if access is permitted.
A profile for redaction could talk about both methods.
Mohammad mentioned interest in redaction for health documents so I was wondering
if there might be existing marking schemes and vocabularies for health records that
might feed into some XACML attribute definitions and concrete examples for a
redaction profile. Anything similar in the military sphere would be interesting too.
Regards,
Steven
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
David Brossard
VP of Customer Relations
+46(0)760 25 85 75
+1 502 922 6538
Axiomatics AB
Västmannagatan 4
S-111 24 Stockholm, Sweden
Support: https://support.axiomatics.com
Web: http://www.axiomatics.com <http://www.axiomatics.com/>
Axiomatics for developers: http://developers.axiomatics.com
Connect with us on LinkedIn <http://www.linkedin.com/companies/536082> | Twitter <http://twitter.com/axiomatics> | Google + <https://plus.google.com/u/1/b/101496487994084529291/> | Facebook <https://www.facebook.com/axiomatics> | YouTube <http://www.youtube.com/user/axiomaticsab>
--
David Brossard
VP of Customer Relations
+46(0)760 25 85 75
+1 502 922 6538
Axiomatics AB
Västmannagatan 4
S-111 24 Stockholm, Sweden
Support: https://support.axiomatics.com
Web: http://www.axiomatics.com
Axiomatics for developers: http://developers.axiomatics.com
Connect with us on LinkedIn | Twitter | Google + | Facebook | YouTube
