[Openid-specs-heart] Vectors of Trust for the Public API - Was: HEART Use Case: Alice Enrolls with PCP

Eve Maler eve.maler at forgerock.com
Mon Jun 29 10:48:50 UTC 2015

Below, a note on the new AG> comment block, eliding the rest. (Sorry I
can't join the call today.)

*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!

On Sat, Jun 27, 2015 at 9:06 AM, Adrian Gropper <agropper at healthurl.com>

> Please see one new comment inline as AG> toward the end.
> On Saturday, June 27, 2015, Debbie Bucci <debbucci at gmail.com> wrote:
>> Comments inline
>> On Fri, Jun 26, 2015 at 6:17 PM, Adrian Gropper <agropper at healthurl.com>
>> wrote:
> ...

>>> D - What changes in the Public API if Verizon and the Hospital are part
>>> of a trust federation and my Apple Authorization Server is completely under
>>> my control ("Apple will not see my Authorization Server or my HealthKit
>>> data")?
>> Not sure I understand this.  The only thing that matter is the binding
>> between the PHR and Hospital for client interactions.   If Hospital is the
>> client then PHR would determine authentication requirements if PHR is the
>> client is the token (fingerprint sensor authentication method) still in
>> play?
> AG> Yes, the client changes within this use case and others. I don't think
> that is relevant in the context of Question D. At any point in time, one
> protected resource on the resource server, is concerned about only one
> resource owner. That one resource owner is linked to the protected resource
> in some way. For the purpose of this question D, let's focus on the
> Hospital as the resource server. The Hospital has a protected resource that
> is associated with one resource owner via a "link" of some sort. What is
> this "link" to the patient? Is it a link to an AS? How was that link
> established?

If the hospital is the *resource server* and has a *protected resource*
that is associated with a specific *resource owner*, and that RO is the
patient, assuming we're using these terms in bold in the UMA sense, then
the patient is capable of managing that resource online at the RS in some
direct fashion, and I would assume has a login/account of some sort there
(it could be federated).

The "link" to an *authorization server* would be formed through the
issuance of a *protection API token*. If the trust model of the ecosystem
allowed the patient a totally free AS choice, then the RS might possibly
offer a NASCAR or similar type of interface to let the RO choose some
typical AS options to ease the process, much as social login often looks
today, or it could offer a field in which to type an AS name, or whatever.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150629/5944a329/attachment.html>

More information about the Openid-specs-heart mailing list