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

Aaron Seib, NATE aaron.seib at nate-trust.org
Mon Mar 27 00:58:34 UTC 2017


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

(m) 301-326-6843

cid:image001.jpg at 01D10761.5BE2FE00

 

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 <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> &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 <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> &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/91d824a9/attachment.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/91d824a9/attachment.jpg>


More information about the Openid-specs-heart mailing list