[Openid-specs-heart] Draft HEART Meeting Notes 2016-03-14

[Adrian Gropper]

Since Eve brought up IoT use-cases during the call (and I love IoT
use-cases) I think it's appropriate to pass on this link
https://medium.com/the-internet-of-me/the-internet-of-things-is-going-to-need-an-internet-of-me-a1d7ed9c0cb2
from the VRM list.

HEART, via UMA, has the opportunity to define what it means for services
and things to come to my technology, at least for notification but also for
authorization, rather than the other way around. Is there any other reason
for us to be in this workgroup?

Adrian

On Mon, Mar 14, 2016 at 6:16 PM, Sarah Squire <sarah at engageidentity.com>
wrote:

> Attending:
>
> Adrian Gropper
>
> Scott Shorter
>
> Sarah Squire
>
> Jim Kragh
>
> Eve Maler
>
> Glen Marshall
>
> Justin Richer
>
> Edmund Jay
>
> Kathleen Connor
>
> Nancy Lush
>
> Jeff Shultz
>
> John Moerke
>
> Dale Moberg
>
> Terminology discussion:
>
> The RPT is a “special snowflake” access token because of the hoops you
> have to jump through to get it in UMA. In spirit, it is an access token.
>
> It would be a good convention in the glossary to specify the source and/or
> relevant protocol of the term in question.
>
> Should we specify what tokens are not? Yes. In fact, NIST is moving toward
> using “token” to refer to OAuth tokens, and “authenticator” to refer to
> multi-factor authentication tools.
>
> Eve:
>
> I’ve taken an action item to make an “uma-flavored” version of our first
> use case. We need to work more on the concept of the requesting party.
>
> John:
>
> You might want to look into FHIR consent.
>
> Kathleen:
>
> In the Privacy on FHIR work, if the requesting device wants an information
> subset, we had to put it on a resource server. Patient directives would
> then be encoded in the authorization server.
>
> Adrian:
>
> UMA doesn’t have to cover the “break glass” scenario.
>
> Eve:
>
> UMA is designed for a resource to be shared with somebody. I sent a “brute
> force” method of specifying what the resource owner and resource server
> wants so that it isn’t liable for what it shouldn’t be liable for. In
> normal UMA, in limited circumstances, we should allow the resource server
> to deny what the authorization server tells it to do.
>
> Kathleen:
>
> A FHIR audit event might be helpful to encourage correct action in those
> cases.
>
> Adrian:
>
> We can build UMA on top of a notice mechanism.
>
> Eve:
>
> In terms of crafting a problem statement that is meaningful, the benefits
> I would look for are consciously deciding who gets access to personal data
> and being able to respond for requests for access. How do we solve sharing
> with medical professionals? Do we use emails directly? What are the claims
> that we ask medical professionals to present realistically?
>
> Sarah:
>
> But that’s out of scope for HEART. It’s up to the owner of the
> implementation what claims they will require or accept.
>
> Adrian:
>
> Yes, but we need at least one use case.
>
> Glen:
>
> I just want something “good enough” particularly a reference
> implementation.
>
> Eve:
> I will take an action item to craft a problem statement.
>
> 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
>
>


-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160314/6bfdd927/attachment.html>