[Openid-specs-heart] Resources vs Resource sets

Tue Jul 26 21:28:38 UTC 2016

I am getting foggy on my understanding of where things are heading.  I follow the notion that magic will happen on the resource server side that will tag data using the confidentiality codes.  What I don’t follow is who does the coding for that informs this magic on how it should work?

It may be a sin amongst this crowd but I am thinking of how DS4P is designed.  There is a code set that gets populated by some “authority”” and the software says – oh this code is found in my table of HIV related codes and I tag it as HIV.  

For me the entire DS4p scheme falls down because no one has the authority to say if you populate your Code sets with these values then you follow the clients preference you are in a safe harbor and no one can ding you for sharing when you shouldn’t.

John – where you say this should include the patient UX am I to understand that for a given code set the every patient will have the opportunity to configure what is in that code set of things that get tagged with a confidentiality code?

I think that is an improvement over DS4P but it still hinges on the question – am I as the RS disclosing a patient’s data doing so in a safe harbor if I allow the patient to customize what they consider sensitive or not?

Or is that the bit of Harry Potter magic that takes place?  Or should we be explicit and say that it is another assumption about the CEs in the role of discloser being compliant if they allow the patient to configure the LOV to aligg with their own sensitivities?

Aaron Seib, CEO

@CaptBlueButton 

 (o) 301-540-2311

(m) 301-326-6843

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of John Moehrke
Sent: Tuesday, July 26, 2016 4:36 PM
To: Eve Maler
Cc: HEART List
Subject: Re: [Openid-specs-heart] Resources vs Resource sets

So. I think best step forward is to say that some magic will happen on the resource server side that will tag data using the _confidentiality codes. This should include patient UX that aids with this setting. Yes it is known today this is poorly done. Default is N when it is not set. 

But setting the tags on the RS is not in HEART scope. It is a precondition.

UMA will control authorization to the various _confidentiality levels. 

UMA can also control resource types.

UMA can also control specific instances of a resource.

Nice clean separation.

John

On Jul 26, 2016 2:56 PM, "Eve Maler" <eve.maler at forgerock.com> wrote:

No, sorry, I meant UMA resource set types -- semantic types, not security labels. Yikes.

 <https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html#resource-set-desc> https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html#resource-set-desc

In other words, we should be defining a profile that literally standardizes UMA resource set types, because that's the only thing in UMA that makes sense to standardize.

I promise never to leave off a qualifying name again, cross my heart. (Uh, no pun intended.)

Eve Maler
ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 <tel:%2B1%20425.345.6756>  | Skype: xmlgrrl | Twitter: @xmlgrrl
ForgeRock Summits and UnSummits are coming to <http://summits.forgerock.com/>  Sydney, London, and Paris!

On Tue, Jul 26, 2016 at 12:26 PM, John Moehrke <johnmoehrke at gmail.com> wrote:

You are reinventing the securityLabels solution that already exists and that I have recommended. It is frustrating that this committee can't focus in what UMA does and leverage the work others have already put in place.

John

On Jul 26, 2016 12:06 PM, "Eve Maler" <eve.maler at forgerock.com> wrote:

If we have Alice check off the FHIR resources she wants to share individually and not share them as a prepackaged "first visit" bundle, then a number of things get a bit easier for the services involved (though the "HIV problem" doesn't get solved).

We can next set about defining UMA resource sets and their attendant scopes for that list of FHIR resources. Note that the scopes can be unique per resource set, but need not be.

I recommend that we plan for these to be profiled UMA resource set types. Alice's instance of a medication list type would differ from Carol's, which would differ from David's, and so on.

Eve Maler
ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 <tel:%2B1%20425.345.6756>  | Skype: xmlgrrl | Twitter: @xmlgrrl
ForgeRock Summits and UnSummits are coming to <http://summits.forgerock.com/>  Sydney, London, and Paris!

On Mon, Jul 25, 2016 at 7:19 PM, Nancy Lush <nlush at lgisoftware.com> wrote:

Hello all,

My sense is that we want to start with a simple example.  Like, Alice can choose which resources she wants to share.  Those can be from the list Debbie displayed today or the list I sent – or whatever the final list turns out to be.  (The list can be changed later.)  But that list is a list of ‘FHIR Resources’.  Alice can choose to share either all, or she can specify which in the list she wishes to share.  (I think this is consistent with Adrian’s most recent ‘b’ point.)

While we can have resource sets, I don’t think we need to confuse the conversation with that yet.

Also, we have talked about confidentiality codes and the desire to have Alice share her conditions, but exclude her HIV condition.  I think as a group we would like to be able to do that, but because it is confusing it takes us off track.  Just temporarily, let’s skip that detail.  

If we start with Alice’s ability to share the FHIR resources, we can work that through the more technical issues, and reach a point where we agree.  We can then add additional detail on top of that.

As a group we all come from different places, often each of those very different places are technical in nature.  As a result, one term can have different meanings to each individual.    I think we are close.  The next step would be to define the flow for this, then bring it back to the team for review.

-Nancy

Nancy Lush          

nancy.lush at lgisoftware.com

Lush Group, Inc

Office: (401) 423-9111 <tel:%28401%29%20423-9111> 

28 Narragansett Ave

PO Box 651

www.lgisoftware.com 

Cell:(401) 965-9347 <tel:%28401%29%20965-9347> 

Jamestown, RI 02835

LGI_logo_small

_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-heart

_______________________________________________
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/20160726/2e466d83/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 3204 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160726/2e466d83/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.gif
Type: image/gif
Size: 3006 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160726/2e466d83/attachment.gif>