[Openid-specs-heart] Taking up the notion of a de-identification scope

[Eve Maler]

Justin and I have been discussing the idea of adding another specialty
scope, somewhat similar to our existing mechanism for
confidentiality/sensitivity scopes and the break-the-glass ("btg") scope,
for indicating that the disclosed data should be de-identified.

The group did discuss this a bit, a long time back, but we put it on the
back burner because de-identification can never be "complete" (i.e., you
never reach full computational anonymization). But there are transformation
processes that do "as good a job as possible", and I believe we can couch
the capability in the right terms. As well, when I have talked with people
about HEART (a lot of people when I was at the RSA conference, for
example!), a demand for this type of feature came up.

Thoughts?

====

In addition, whether we have two (conf/sens and btg) or three (adding
de-id) such mechanisms, I think the spec would really benefit from a bit
more text explaining the consequences of how they work -- and possibly how
they might compare to each other. We've got the bare minimum spec text
right now. Currently, things work like this:

   - In all cases: RS has the choice to advertise the capability to handle
   each scope, in OAuth, by including it in developer documentation, and in
   UMA, by registering the scope as part of a registered resource. (This means
   it's not possible for an AS to be caught unawares offering a scope that an
   RS can't handle.)


   - Conf/sens scopes: If the scope is MISSING from a client-presented
   access token, the RS SHOULD filter out the corresponding conf/sens data.

   Implications that we don't describe anywhere yet:

   - The SHOULD is a very strong word in spec writing, but we don't say
      what the rationales should be for *not* being able to filter out the
      data as "promised".

      - Given that *absence* of the scope is a signal to filter (this is
      because the scope names are based on the HL7 codes and the way the "logic
      direction" runs), "default policies" or similar in the patient's UX that
      automatically set up filtering would be a good idea.


   - btg: If the scope is PRESENT in a client-presented access token, then
   the RS MUST leave a human-readable audit trail of access given on that
   basis.

   Implications that we don't describe anywhere yet:

   - Pre-set policies would be a big benefit here given that we say "The
      resource is intended to be accessed when the resource owner is
      unavailable", a UX consideration but an important one.

      - It's likely that setting up some sort of trust framework or similar
      will be needed for determining which claims would suffice for
letting (say)
      an emergency responder get access when the resource owner is unavailable.

I suspect that if we add something like a "de-identify" scope, its logic
would work OPPOSITE to the conf/sens scopes because we could name it in a
more obvious fashion. And so if it were PRESENT in a client-presented
access token, that would be the signal for the RS to do the
de-identification operation on delivered content.

(Refer to this spec
<http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=html/ascii&url=https://bitbucket.org/openid/heart/raw/master/openid-heart-fhir-oauth2.xml>
for the relevant language.)

====

We do have a meeting on Monday, and I apologize for having to miss it --
I'll be in Munich at the EIC conference, presenting HEART status to the
OpenID Foundation workshop, for one thing!

[image: ForgeRock] <https://www.forgerock.com/> *Eve Maler*
VP Innovation & Emerging Technology  |  ForgeRock
*t* (425) 345-6756  |  *e* eve.maler at forgerock.com
*twitter* xmlgrrl  |  *web* www.forgerock.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20180512/4a4f69d1/attachment.html>