[Openid-specs-heart] Resources vs Resource sets

[John Moehrke]

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/1919169d/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/1919169d/attachment.gif>