[Openid-specs-heart] HEART profiling for sensitive data

[Eve Maler]

I actually think we're coming close to a happy medium (or something) with
what Nancy is proposing, with the sentiment that others are expressing in
the thread, and with candidate text that's appearing in our spec drafts now.

Let us assume for a moment that tags (applied by an RS) that obscure what
information is "behind" them (such as "this is highly sensitive" without
revealing the categories considered sensitive, or "PSY" without spelling
out "Psychiatry Related") could receive UX assistance. The cool thing about
the ability for a resource owner to control sharing is that such scopes are
just *made available* for Alice's use over at the AS. There's a separation
of concerns; the RS can mark the resources during registration, but Alice
still gets to control access based on the markings if she feels like it.

And note that we've made a bit of progress since Nancy and I first
discussed the topic and put together the initial proposal wording, which
flagged potential technical issues. Justin was able to translate our WG
discussions into some text, which I recommend we look at specifically to
see if we want to change it. I, for one, think it's technically viable.

*First:* OAuth+FHIR Sec 3 and Sec 4:
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#rfc.section.3

Specifically, see the listings of conf/N and so on, and also "Additional
confidentiality and sensitivity scopes can be defined by [[ IANA or other
registry process ]]."

This section defines five *specific* OAuth scopes (with a sixth in the next
section), and an *extension* mechanism by which any additional set of
scopes can be used from an external specification. (The mechanism is to be
determined...) Does it look like this would work for OAuth?

*Second:* UMA+FHIR Sec 2.2:
http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=html/ascii&url=https://bitbucket.org/openid/heart/raw/master/openid-heart-fhir-uma.xml#rfc.section.2.2

Specifically, this language: "Additionally, the resource MAY use any of the
scopes defined in [HEART.OAuth2.FHIR] regarding confidentiality,
sensitivity, or emergency (break the glass)."

This section enables usage of scopes in UMA of any of the
cross-cutting OAuth scopes defined in (or through) Sections 3 and 4 in the
OAuth+FHIR spec. Does it look like this would work for UMA?


*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Sun, Mar 26, 2017 at 5:02 PM, Debbie Bucci <debbucci at gmail.com> wrote:

> We are trying to finish up the final semantic profile.
> HEART profiles does not deal with UI issues
> Nor would it define how to technical information is tagged.
>
> That said, if a resource server is able to tag information - perhaps the
> AS should be aware.
>
> I thought John originally suggested we should start focus on the
> confidentiality code as a start - and I think that is what Nancy is
> suggesting - with a bit more context.
>
> Terminology may not be perfect and cover all use cases but certainly there
> is a use case or two that we could give examples for.   The two that Nancy
> suggest - seem general enough for a good start.  Odds are that patient
> would understand and could express the level of data (confidentiality code)
> to release.
>
> ETH – Substance Abuse
>
> PSY – Psychiatry Related
>
> I have to keep reminding myself that This dance would ONLY occur if the RS
> relayed to the AS it will support it.
>
>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20170326/ae597e07/attachment.html>