[Openid-specs-heart] Resources vs Resource sets

Tue Jul 26 21:39:09 UTC 2016

Would a metaphor of files and folders help us talk about this? E.g. Alice
can set different permissions on her 'medications' file than she sets on
the 'first visit' folder that the file lives within?

Sarah Squire
Engage Identity
http://engageidentity.com

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

> 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
>>
>> 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 | 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 | 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
>>>>>
>>>>> 28 Narragansett Ave
>>>>>
>>>>> PO Box 651
>>>>>
>>>>> www.lgisoftware.com
>>>>>
>>>>> Cell:(401) 965-9347
>>>>>
>>>>> Jamestown, RI 02835
>>>>>
>>>>>
>>>>>
>>>>> [image: 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
>>>>
>>>>
>>
> _______________________________________________
> 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/9c0ffb0c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 3006 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160726/9c0ffb0c/attachment.gif>