[Openid-specs-heart] Draft HEART Meeting Notes 2016-09-12

Eve Maler eve.maler at forgerock.com
Tue Sep 13 11:48:36 UTC 2016


I thought "first visit" was the specific circumstance that gave form,
shape, and purpose to *why* Alice was sharing her data in the first place
(for example, different data may be involved if it's a first visit vs. if
it's a switch in doctors, which means the resource set profiling might be
different). Otherwise, why is Alice taking this action?

(Another circumstance could be "Alice shares her medication list (or
allergies list) with her husband". This is something I'd like to do.)

But I may be wrong.


*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/> *London and Paris!*

On Tue, Sep 13, 2016 at 1:31 PM, Nancy Lush <nlush at lgisoftware.com> wrote:

> In keeping with the objective of ‘we need to significantly narrow this
> document’ we should not be diverted by the “first visit” in this first
> pass.  That should be added to the list of ‘challenges’ that need to be
> discussed and addressed later.  We are having difficulty just finishing one
> simple user story using the full set of technology we would like to use.
> We are continually bogged down in the exceptions.
>
>
>
> Keep it simple, that is complicated enough:  Alice proactively gives Dr.
> Bob access to all of her basic data.
>
> I suspect that once we walk through this story completely, then the others
> will be much simpler to expand.
>
>
>
> -Nancy
>
>
>
> *From:* Openid-specs-heart [mailto:openid-specs-heart-
> bounces at lists.openid.net] *On Behalf Of *Eve Maler
> *Sent:* Tuesday, September 13, 2016 4:34 AM
> *To:* Sarah Squire <sarah at engageidentity.com>
> *Cc:* HEART List <openid-specs-heart at lists.openid.net>
> *Subject:* Re: [Openid-specs-heart] Draft HEART Meeting Notes 2016-09-12
>
>
>
> Hi folks-- Sorry I couldn't make this meeting due to my travel. I agree
> with getting more specific about the use cases. This is what the "flows"
> were/are supposed to accomplish. Did people look at those on the call? One
> question of specificity that came up earlier was sharing "first visit" data
> prior to going to the appointment vs. arranging for transfer of records
> when switching doctors. We could imagine a matrix of these two against the
> option of proactive (Alice shares) vs. reactive (Alice approves an access
> request) flows.
>
>
>
> Regarding delegating access to the policies themselves, I continue to
> think that this is "PhD-level UMA" (or not an UMA use case, e.g., XACML or
> something), and Occam's Razor suggests leaving this this out unless/until
> someone can state the specific need for Alice to share her policies. Then
> we'd know the context(s) for doing so.
>
>
>
> *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/> *London and Paris!*
>
>
>
> On Mon, Sep 12, 2016 at 11:07 PM, Sarah Squire <sarah at engageidentity.com>
> wrote:
>
> Attendees:
>
> Debbie Bucci
>
> Adrian Gropper
>
> Dale Moberg
>
> Edmund Jay
>
> Glen Marshall
>
> Jim Kragh
>
> Julie Maas
>
> Kenneth Salyards
>
> Luis Maas
>
> Nancy Lush
>
> Sarah Squire
>
> Thomas Sullivan
>
> Walter Kirk
>
>
>
> Debbie:
>
> Meeting is still on for September 19th.
>
> MEETING CANCELLED on September 26th.
>
>
>
> Sarah:
>
> The UMA use case as it stands now (https://bitbucket.org/openid/
> heart/wiki/Alice_Shares_with_Physicians_and_Others_UMA_FHIR) is extremely
> broad and talks about a lot of different scenarios. If we want to optimize
> for interoperability (which I think we do) we need to significantly narrow
> this document. I think it might help to write a few short user stories -
> things like “Dr. Bob can request Alice’s current medications” “Alice can
> reactively approve or deny Dr. Bob’s request.”
>
>
>
> Smaller bite-size stories like this will make it much easier for us to
> actually write the spec and make sure that the features we want are
> possible in a wide-ecosystem cross-domain context without any requirement
> for systems to agree beforehand on how to format requests across the wire.
>
>
>
> Does that make sense?
>
>
>
> Nancy:
>
> I agree completely.
>
>
>
> Debbie:
>
> Is the suggestion to boil this down to smaller peices?
>
>
>
> Sarah:
>
> Right, shorter user stories that indicate specific features.
>
>
>
> Adrian:
>
> Do we need to discuss how Dr. Bob got the address for the resource?
>
>
>
> Sarah:
>
> We talk a little about that in the security profile, I think maybe we
> suggest webfinger? We could certainly talk about it more in the semantic
> profile.
>
>
>
> Debbie:
>
> Is there something we should start walking through?
>
>
>
> Sarah:
>
> My question to the group is whether there are things in this use case,
> flows or functionality, that we don’t want to profile?
>
>
>
> Glen:
>
> I don’t think we should address discovery beyond recommendations. It would
> be a significant increase in scope.
>
>
>
> Sarah:
>
> Agreed
>
>
>
> Adrian:
>
> But we do have to be clear about how we relate resource discovery to the
> use cases that we present.
>
>
>
> Nancy:
>
> Let’s note that it exists and revisit it later.
>
>
>
> Debbie:
>
> Is there anything in the Data and Services section that we would take out?
>
>
>
> Sarah:
>
> We need to figure out which features and flows we want to enable and how
> one server would indicate to another server which flow it is using.
>
>
>
> Adrian:
>
> Can we do the medications use case first?
>
>
>
> Sarah:
>
> It’s actually irrelevant which FHIR resource we talk about. We don’t
> define the FHIR taxonomy. We are talking about features and flows that we
> will need to enable.
>
>
>
> Nancy:
>
> We can use medication as an example, but we should be generic in the
> specification as to which FHIR resource we are talking about.
>
>
>
> Ken:
>
> I don’t think it’s scalable to have a patient decide the policies on their
> resources.
>
>
>
> Debbie:
>
> It will be much simpler in practice. I do think that a patient will be
> able to say “share my medication list with Dr. Bob”
>
>
>
> Sarah:
>
> So, for example, we need to decide whether we want a proactive or reactive
> flow or both.
>
>
>
> Debbie:
>
> So I think we’ve always said that consent and delegation are in scope.
>
>
>
> Sarah:
>
> So we’re looking at the “Summary of sharing scenarios” section of the
> document. Do we want to profile all of these flows? We also need to profile
> how claims are going to work. If Alice is proactively setting policies, she
> will need to indicate what claims Dr. Bob has to fulfill before he gets
> access to her resources.
>
>
>
> Debbie:
>
> I would also like to see a flow where Alice delegates access.
>
>
>
> Sarah:
>
> Are we talking about delegating access to data? Or access to the policies
> themselves?
>
>
>
> Debbie:
>
> The policies themselves.
>
>
>
> Sarah:
>
> Okay, because there’s really no concept of that in the UMA protocol. It
> would just be switching the Resource Owner.
>
>
>
> Debbie:
>
> So we can talk about that in the spec. Maybe just make it auditable.
>
>
>
> Sarah Squire
>
> Engage Identity
>
> http://engageidentity.com
>
>
> _______________________________________________
> 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/20160913/23566f36/attachment-0001.html>


More information about the Openid-specs-heart mailing list