[Openid-specs-heart] Resources vs Resource sets

Tue Jul 26 20:36:21 UTC 2016

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
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160726/3a1e8f1d/attachment-0001.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/3a1e8f1d/attachment-0001.gif>