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

[Eve Maler]

Here's how I've come to understand it. RS's have some sort of duty to *mark*
data according to their interpretation, and we're giving them the ability
to include that interpretation (through our profiling) as they register
resources for protection at the AS. This gives the AS the ability to offer
the markings up as dimensions of policy-setting to Alice.

But the RS has nothing to do with *making* Alice share or not share data on
the basis of the markings. And It's possible for the AS to offer handy
defaults in Alice's "defense", and give her fine-grained control, if she
wants it, over sharing "sensitive data as perceived by others" and not
sharing "non-sensitive data as perceived by others". And a sophisticated AS
could even offer value-add interfaces that give her the ability to add her
own markings, a la the demos I've given from time to time -- adding
Gmail-style labels of her own or whatever.


*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:58 PM, Aaron Seib, NATE <aaron.seib at nate-trust.org
> wrote:

> Eve, you say
>
>
>
> “the RS can mark the resources during registration, but Alice still gets
> to control access based on the markings if she feels like it.”
>
>
>
> I am not sure I follow.  Can Alice accept the markings and indicate she
> disagrees in certain cases and over-ride the recommendation at a granular
> level.
>
>
>
> More importantly – to me – if there is something that Alice feels is
> sensitive but the RS didn’t tag it as sensitive does Alice have a way of
> saying I am sensitive about this diagnosis – or in the case of historically
> stigmatized diagnosis and treatments – I am no longer sensitive about this
> and for me I want you to share this even if the reulatory paradigm says you
> shouldn’t?
>
>
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311 <(301)%20540-2311>
>
> (m) 301-326-6843 <(301)%20326-6843>
>
> [image: cid:image001.jpg at 01D10761.5BE2FE00] <http://nate-trust.org>
>
>
>
> *From:* Openid-specs-heart [mailto:openid-specs-heart-
> bounces at lists.openid.net] *On Behalf Of *Eve Maler
> *Sent:* Sunday, March 26, 2017 8:26 PM
> *To:* Debbie Bucci
> *Cc:* HEART List
> *Subject:* Re: [Openid-specs-heart] HEART profiling for sensitive data
>
>
>
> 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 <(425)%20345-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/a8b7a04c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20170326/a8b7a04c/attachment-0001.jpg>