[Openid-specs-heart] HEART 2015-08-05 meeting notes

[Maxwell, Jeremy (OS/OCPO)]

No worries.  I’m just trying to understand how we think this will happen in practice.  So for my wife (non-techie), what is her resource server?  When she goes into her provider, what does she have to provide?

Sorry if I’m being dense or revisiting things that have already been discussed.  I missed about 4 weeks of discussion so I’m trying to catch up.  I’m trying to understand what the workflow looks like to a non-techie patient.



From: jmandel at gmail.com [mailto:jmandel at gmail.com] On Behalf Of Josh Mandel
Sent: Thursday, August 06, 2015 10:52 AM
To: Aaron Seib
Cc: Maxwell, Jeremy (OS/OCPO); jim kragh; Debbie Bucci; openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes

Apologies if this was totally unclear. The "Dear Dr. Jones..." statement was meant to capture what it means for a resource owner to introduce a resource server to an authorization server (in UMA terms). Does this help at all?

  -J

On Thu, Aug 6, 2015 at 10:16 AM, Aaron Seib <aaron.seib at nate-trust.org<mailto:aaron.seib at nate-trust.org>> wrote:
I am not sure I even understand the statement highlighted in yellow accurately yet.  ☺

That might be a start.  Predetermined choice token means?  Confidential token choice?

Aaron

Aaron Seib
NATE<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.nate-2Dtrust.org_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=z8Y3dTNXfeIHTJOVrFI1AbuFBtR0weR9H30VsLiwJME&s=tgDfJWZHjbfBbL_Yrkm82b9zJxfIA-nZsaQ9nf5XQ5c&e=>, CEO
@CaptBlueButton
(o) 301-540-2311<tel:301-540-2311>
(m) 301-326-6843<tel:301-326-6843>


From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net<mailto:openid-specs-heart-bounces at lists.openid.net>] On Behalf Of Maxwell, Jeremy (OS/OCPO)
Sent: Thursday, August 6, 2015 9:41 AM
To: jim kragh; Debbie Bucci

Cc: openid-specs-heart at lists.openid.net<mailto:openid-specs-heart at lists.openid.net>
Subject: Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes


The pre determined choice token confidential token choice and exactly what information needs (example: PHR's authorization endpoint)  to be shared in advance between the PCP's EHR and Alice's PCP was left out of the discussion for now.

Perfectly fine with leaving this in the parking lot for now, but before we’re done we need to have very clear setup/configuration/implementation guidance.  It needs to be clear and easy to setup and use.  If we add a bunch of configuration steps it will be additional hurdles to adoption.  Remember, many folks have struggled with certificate and trust bundle management in Direct.  So we need to at least be simpler than that.


From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of jim kragh
Sent: Wednesday, August 05, 2015 8:28 PM
To: Debbie Bucci
Cc: openid-specs-heart at lists.openid.net<mailto:openid-specs-heart at lists.openid.net>
Subject: Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes

Thanks for sharing,...  informative and constructive in reaching the patient end point.

May all have a nice evening!

On Wed, Aug 5, 2015 at 3:26 PM, Debbie Bucci <debbucci at gmail.com<mailto:debbucci at gmail.com>> wrote:
Attendees:
Eve Maler
Justin Richer
Josh Mandel
Adrian Gropper
Thomas Sullivan
Debbie Bucci

We have decided to delineate between mechanical and semantic scope docs.

For the PCP <-> PHR use case:

The pre determined choice token confidential token choice and exactly what information needs (example: PHR's authorization endpoint)  to be shared in advance between the PCP's EHR and Alice's PCP was left out of the discussion for now.

There is one basic mechanical Oauth  generic flow that occurs twice in the use case.

Given the group has generally agreed that the SMART specifications are a good place to start ... for this particular use case  the only semantic FHIR scope that is necessary is the patient/*.read scope that grants permission to read any resource for the current patient.

During the registration process Alice should be able to select at a fine grain level which resources she is willing to share with the PHR.   This mimic's a specific process - Adrian please provide.  This information will be used to generate the access token.

The one thing left at the end of the discussion is whether the patient record is implicit or explicitly stated.  This is a design decision that may make a difference as we move towards our next use case in which delegation is a factor.

Corrections/updates appreciated.



_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net<mailto:Openid-specs-heart at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-heart<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=z8Y3dTNXfeIHTJOVrFI1AbuFBtR0weR9H30VsLiwJME&s=8XR3NIglMh-Fdi8Tn07unv1E52KNE5BIepwuZRF7Vr0&e=>


_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net<mailto:Openid-specs-heart at lists.openid.net>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQICAg&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=z8Y3dTNXfeIHTJOVrFI1AbuFBtR0weR9H30VsLiwJME&s=8XR3NIglMh-Fdi8Tn07unv1E52KNE5BIepwuZRF7Vr0&e=

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150806/655ed352/attachment-0001.html>