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

[Eve Maler]

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/d129918a/attachment.html>