[Openid-specs-heart] Openid-specs-heart Digest, Vol 112, Issue 4

Kathleen Connor kathleen_connor at comcast.net
Thu Mar 2 02:52:18 UTC 2017


Whether a patient has control over disclosures related to emergency purpose
of use is very much a local policy issue and should not be taken as a given.

HEART should remain policy agnostic but policy enabling.

-K

Kathleen Connor
Baycliffe Strategies, Inc.
Office - 360 357 3536 [Primary]
Cell - 360 480 7599 
-----Original Message-----
From: Openid-specs-heart
[mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of
openid-specs-heart-request at lists.openid.net
Sent: Wednesday, March 01, 2017 12:11 PM
To: openid-specs-heart at lists.openid.net
Subject: Openid-specs-heart Digest, Vol 112, Issue 4

Send Openid-specs-heart mailing list submissions to
	openid-specs-heart at lists.openid.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.openid.net/mailman/listinfo/openid-specs-heart
or, via email, send a message with subject or body 'help' to
	openid-specs-heart-request at lists.openid.net

You can reach the person managing the list at
	openid-specs-heart-owner at lists.openid.net

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Openid-specs-heart digest..."


Today's Topics:

   1. Re: Comments on the UMA+FHIR profile (and one additional
      profile comment) (Ioana Singureanu)
   2. Re: Comments on the UMA+FHIR profile (and one additional
      profile comment) (Ioana Singureanu)
   3. Re: Comments on the UMA+FHIR profile (and one additional
      profile comment) (John Moehrke)
   4. Re: Comments on the UMA+FHIR profile (and one additional
      profile comment) (Adrian Gropper)


----------------------------------------------------------------------

Message: 1
Date: Tue, 28 Feb 2017 11:05:26 -0500
From: Ioana Singureanu <ioana.singureanu at gmail.com>
To: Nancy Lush <nlush at lgisoftware.com>
Cc: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Comments on the UMA+FHIR profile
	(and one additional profile comment)
Message-ID:
	<CAHWcvBo5bEckZHzi3AyzLzVqGddRzGV3Fp8ho46qk85Qu3fLOw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

HI Nancy et al;


For patient safety, theUMA policy would not be invoked in cases when the
user/initiator asserts the purpose of the request is "emergency" (rather
"treatment" or "research").   For simplicity, we could assume that any
consent or UMA policy will never refer to"emergency treatment" or "ER"
because it simply does not matter in those cases.

As a use cases, it may be a useful to address "emergency" but from an
information flow it's trivial, the UMA would be disregarded. If the client
is authorized, they will get *all *the data requested even if it's
restricted.

Cheers,
Ioana Singureanu


On Mon, Feb 27, 2017 at 7:36 PM, Nancy Lush <nlush at lgisoftware.com> wrote:

> Re:  But I also wonder if, in practice, there will be other true 
> role-based claims that would supplant the er/btg claim in practice.
>
> Good thought.  I had a problem using er for Emergency Responder as I 
> always think of the ER as Emergency Room.  Granted, they may both need 
> to BTG, but the Emergency Room role is typically within a hospital 
> setting and the Emergency Responder may be a deputized citizen.  I do 
> believe that Emergency Responders represent a hole in our 
> interoperability use cases that need attention.  Will be good to see 
> Glen?s whitepaper and understand the issue more holistically.
>
>
>
> Thanks Justin.
>
>
>
> -Nancy
>
>
>
> *From:* Openid-specs-heart [mailto:openid-specs-heart- 
> bounces at lists.openid.net] *On Behalf Of *Eve Maler
> *Sent:* Monday, February 27, 2017 5:28 PM
> *To:* openid-specs-heart at lists.openid.net
> *Subject:* [Openid-specs-heart] Comments on the UMA+FHIR profile (and 
> one additional profile comment)
>
>
>
> Great stuff!
>
>
>
> UMA+FHIR profile:
>
>    - User-Managed Access should have a hyphen throughout.
>    - As you already noted, the "openid-heart-fhir-oauth2" needs to be
>    changed.
>    - Claim semantics: Make this their own section (keeping the
>    positioning at Sec 3 is fine), and make sure to register them in the
OIDC
>    JWT claims registry. We could have a separate section (what is
currently
>    the introduction to Sec 3) discussing Claims Presentation, but I'm not
sure
>    this is warranted. Instead, the intro to discussing claim semantics
could
>    make clear that claims MAY be pushed or interactively gathered. (We
haven't
>    yet defined any claim profiles for pushed claims, but we should
probably
>    consider this: OIDC, I assume?)
>    - src claim: I wasn't sure if this would keep the same name, but it
>    should probably be "licensing" (or "accreditation") "*authority*"
>    (rather than "board") to be a bit more generic.
>    - Food for thought: For the same reason that "airplane mode" is an
>    awkward name for turning off cell signal reception on your mobile
device --
>    it's too specific -- maybe the "er" claim should be called "btg" to
match
>    the scope name. But I also wonder if, in practice, there will be other
true
>    role-based claims that would supplant the er/btg claim in practice. In
>    which case, Sec 4.1 could simply have a SHOULD or MUST around enabling
the
>    resource owner to audit the specific "btg"-related policies in place
along
>    with making any access ultimately granted auditable and available to
the
>    resource owner, etc.
>    - In UMA2, we've learned that the RS should document its pattern of
>    permission requests ("registrations"), and this may be relevant for
>    profiling UMA1 as well. It would help the client know what sort of
stuff it
>    may be getting in its RPT.
>    - in Section 4: s/implementors/implementers/
>
>
>
> UMA profile:
>
>    - TTL of the PAT: The advice given is generic, referring to the OAuth
>    profile. But the PAT specifically needs to be used in an "offline"
>    (asynchronous) way most of the time (on client access attempts) and for
>    most use cases (when the requesting party isn't the same as the
resource
>    owner). Should we say something specific about this? The UMA
Implementers'
>    Guide does
>
<http://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Gui
de?src=contextnavchildmode#UMAImplementer'sGuide-RO-offlineEnsuringAsynchron
ousResourceServerAccesstoanAuthorizationServer>
>    .
>
>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging 
> Technology Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | 
> Twitter:
> @xmlgrrl
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>


-- 
   Ioana Singureanu
   Eversolve, LLC
   T: 603 548 5640
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openid.net/pipermail/openid-specs-heart/attachments/20170228/c
d5cff1c/attachment-0001.html>

------------------------------

Message: 2
Date: Wed, 1 Mar 2017 00:43:48 -0500
From: Ioana Singureanu <ioana.singureanu at gmail.com>
To: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Comments on the UMA+FHIR profile
	(and one additional profile comment)
Message-ID:
	<CAHWcvBpzaWz7Jo1J8WKpBOw5kP0LArP+0Hmm8i9-MaG72z6kZA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Indeed...We already have a policy that mandates that we auditing all
"disclosure" events regardless of purpose (aka "accounting for disclosure").
If an initiator asserts "emergency", "treatment",  or "research"...  we have
to record who, when, and what information was shared.

Cheers,
Ioana

On Tue, Feb 28, 2017 at 11:08 PM, Eve Maler <eve.maler at forgerock.com> wrote:

> Okay. But it could be accounted for by making it visible in the same 
> system the patient uses for the policies they do set. As I say, 
> accountability would increase if it's auditable in the same way as 
> everything else. I'm familiar with an emergency first-responder system 
> (firefighters and the like) put in place by a telco, where they're 
> using identity claims that need to be part of a trust framework. The 
> same could be used here, with policies set by the AS and agreed to through
the Ts & Cs.
>
>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging 
> Technology Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | 
> Twitter:
> @xmlgrrl
>
> On Tue, Feb 28, 2017 at 6:42 PM, Ioana Singureanu < 
> ioana.singureanu at gmail.com> wrote:
>
>> Hi Eve:
>>
>> Just a clarification: emergency access (aka "break the glass") is not 
>> an exception but rather type authorization policy but that that 
>> cannot be modulated by patient through a consent. HIEs implement the 
>> "break the glass" policy *explicitly *along with other policies.
>> It's not an exception, but just another policy. From an UMA 
>> stand-point it's not a very interesting policy because the patient has no
input.
>>
>> Kind regards,
>> Ioana
>>
>> On Tue, Feb 28, 2017 at 2:38 PM, Eve Maler <eve.maler at forgerock.com>
>> wrote:
>>
>>> The interesting thing about having the HEART profile(s) cover this 
>>> use case is that the sharing of the data goes from an exception 
>>> basis to an in-band, auditable, patient-involved (yet still 
>>> lightweight) basis, where the other parties know they're responsible 
>>> for proving (later) that there was a legitimate reason for the 
>>> access based on their trust of the requesting party's claims. 
>>> Accountability can go way up, and access involves using the "same
technology stack as usual".
>>>
>>> This is as opposed to current practice; a study I saw a few years 
>>> ago for a European country showed that ~70% of hospital record 
>>> access in one case was exception-based vs. rule-based -- and that's 
>>> in a provider-to-provider scenario. I bet no one is surprised.
>>>
>>> Eve (from my iPad)
>>>
>>> On Feb 28, 2017, at 8:05 AM, Ioana Singureanu < 
>>> ioana.singureanu at gmail.com> wrote:
>>>
>>> HI Nancy et al;
>>>
>>>
>>> For patient safety, theUMA policy would not be invoked in cases when 
>>> the user/initiator asserts the purpose of the request is "emergency"
(rather
>>> "treatment" or "research").   For simplicity, we could assume that any
>>> consent or UMA policy will never refer to"emergency treatment" or "ER"
>>> because it simply does not matter in those cases.
>>>
>>> As a use cases, it may be a useful to address "emergency" but from 
>>> an information flow it's trivial, the UMA would be disregarded. If 
>>> the client is authorized, they will get *all *the data requested 
>>> even if it's restricted.
>>>
>>> Cheers,
>>> Ioana Singureanu
>>>
>>>
>>> On Mon, Feb 27, 2017 at 7:36 PM, Nancy Lush <nlush at lgisoftware.com>
>>> wrote:
>>>
>>>> Re:  But I also wonder if, in practice, there will be other true 
>>>> role-based claims that would supplant the er/btg claim in practice.
>>>>
>>>> Good thought.  I had a problem using er for Emergency Responder as 
>>>> I always think of the ER as Emergency Room.  Granted, they may both 
>>>> need to BTG, but the Emergency Room role is typically within a 
>>>> hospital setting and the Emergency Responder may be a deputized 
>>>> citizen.  I do believe that Emergency Responders represent a hole 
>>>> in our interoperability use cases that need attention.  Will be 
>>>> good to see Glen?s whitepaper and understand the issue more
holistically.
>>>>
>>>>
>>>>
>>>> Thanks Justin.
>>>>
>>>>
>>>>
>>>> -Nancy
>>>>
>>>>
>>>>
>>>> *From:* Openid-specs-heart [mailto:openid-specs-heart-bou 
>>>> nces at lists.openid.net] *On Behalf Of *Eve Maler
>>>> *Sent:* Monday, February 27, 2017 5:28 PM
>>>> *To:* openid-specs-heart at lists.openid.net
>>>> *Subject:* [Openid-specs-heart] Comments on the UMA+FHIR profile 
>>>> (and one additional profile comment)
>>>>
>>>>
>>>>
>>>> Great stuff!
>>>>
>>>>
>>>>
>>>> UMA+FHIR profile:
>>>>
>>>>    - User-Managed Access should have a hyphen throughout.
>>>>    - As you already noted, the "openid-heart-fhir-oauth2" needs to be
>>>>    changed.
>>>>    - Claim semantics: Make this their own section (keeping the
>>>>    positioning at Sec 3 is fine), and make sure to register them in the
OIDC
>>>>    JWT claims registry. We could have a separate section (what is
currently
>>>>    the introduction to Sec 3) discussing Claims Presentation, but I'm
not sure
>>>>    this is warranted. Instead, the intro to discussing claim semantics
could
>>>>    make clear that claims MAY be pushed or interactively gathered. (We
haven't
>>>>    yet defined any claim profiles for pushed claims, but we should
probably
>>>>    consider this: OIDC, I assume?)
>>>>    - src claim: I wasn't sure if this would keep the same name, but it
>>>>    should probably be "licensing" (or "accreditation") "*authority*"
>>>>    (rather than "board") to be a bit more generic.
>>>>    - Food for thought: For the same reason that "airplane mode" is an
>>>>    awkward name for turning off cell signal reception on your mobile
device --
>>>>    it's too specific -- maybe the "er" claim should be called "btg" to
match
>>>>    the scope name. But I also wonder if, in practice, there will be
other true
>>>>    role-based claims that would supplant the er/btg claim in practice.
In
>>>>    which case, Sec 4.1 could simply have a SHOULD or MUST around
enabling the
>>>>    resource owner to audit the specific "btg"-related policies in place
along
>>>>    with making any access ultimately granted auditable and available to
the
>>>>    resource owner, etc.
>>>>    - In UMA2, we've learned that the RS should document its pattern of
>>>>    permission requests ("registrations"), and this may be relevant for
>>>>    profiling UMA1 as well. It would help the client know what sort of
stuff it
>>>>    may be getting in its RPT.
>>>>    - in Section 4: s/implementors/implementers/
>>>>
>>>>
>>>>
>>>> UMA profile:
>>>>
>>>>    - TTL of the PAT: The advice given is generic, referring to the
>>>>    OAuth profile. But the PAT specifically needs to be used in an
"offline"
>>>>    (asynchronous) way most of the time (on client access attempts) and
for
>>>>    most use cases (when the requesting party isn't the same as the
resource
>>>>    owner). Should we say something specific about this? The UMA
Implementers'
>>>>    Guide does
>>>>
<http://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Gui
de?src=contextnavchildmode#UMAImplementer'sGuide-RO-offlineEnsuringAsynchron
ousResourceServerAccesstoanAuthorizationServer>
>>>>    .
>>>>
>>>>
>>>> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging 
>>>> Technology Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl 
>>>> | Twitter:
>>>> @xmlgrrl
>>>>
>>>> _______________________________________________
>>>> Openid-specs-heart mailing list
>>>> Openid-specs-heart at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>>>
>>>>
>>>
>>>
>>> --
>>>    Ioana Singureanu
>>>    Eversolve, LLC
>>>    T: 603 548 5640 <(603)%20548-5640>
>>>
>>>
>>
>>
>> --
>>    Ioana Singureanu
>>    Eversolve, LLC
>>    T: 603 548 5640 <(603)%20548-5640>
>>
>
>


-- 
   Ioana Singureanu
   Eversolve, LLC
   T: 603 548 5640
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openid.net/pipermail/openid-specs-heart/attachments/20170301/c
2739be6/attachment-0001.html>

------------------------------

Message: 3
Date: Wed, 1 Mar 2017 14:00:45 -0600
From: John Moehrke <johnmoehrke at gmail.com>
To: Ioana Singureanu <ioana.singureanu at gmail.com>
Cc: HEART List <openid-specs-heart at lists.openid.net>
Subject: Re: [Openid-specs-heart] Comments on the UMA+FHIR profile
	(and one additional profile comment)
Message-ID:
	<CACDGQjuw0FJftQ0T5xTt9hAwzWZnBSX7hSDnBSWB4udS_3B6WA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I have a different 'policy' than the one Ioana outlines.

First we need to get good clarity. "Emergency Department" is not the same
thing as Break-Glass (aka Medical-Emergency-Override). Where the these
Break-Glass accesses might happen more often from the Emergency Department,
but normal access from the emergency department would be... "normal"... The
people who work in the Emergency Room carry structural and functional roles
that represent the job the are performing; those 'roles' usually enable a
high privilege access.

Break-Glass is a case where an authorized individual is enabled to request
privilege elevation. That privilege elevation is not absolute. This is where
Ioana and I differ. I am willing to allow discussion of a UMA policy that
mediates this privilege elevation. Indeed UMA might be the arbitrator of who
is allowed to request break-glass; or what settings allow it. There are
cases where patients really want no access by specific individuals; even if
it means pain/suffering/death to the patient. It is their right to declare
these policies.

The important part is that UMA be engaged at all time.

That said, there are medical-practice issues with this model. (as well as
operational reliability and availability).

John

John Moehrke
Principal Engineering Architect: Standards - Interoperability, Privacy, and
Security CyberPrivacy ? Enabling authorized communications while respecting
Privacy M +1 920-564-2067 JohnMoehrke at gmail.com
https://www.linkedin.com/in/johnmoehrke
https://healthcaresecprivacy.blogspot.com
"Quis custodiet ipsos custodes?" ("Who watches the watchers?")

On Tue, Feb 28, 2017 at 11:43 PM, Ioana Singureanu <
ioana.singureanu at gmail.com> wrote:

> Indeed...We already have a policy that mandates that we auditing all 
> "disclosure" events regardless of purpose (aka "accounting for 
> disclosure"). If an initiator asserts "emergency", "treatment",  or 
> "research"...  we have to record who, when, and what information was
shared.
>
> Cheers,
> Ioana
>
> On Tue, Feb 28, 2017 at 11:08 PM, Eve Maler <eve.maler at forgerock.com>
> wrote:
>
>> Okay. But it could be accounted for by making it visible in the same 
>> system the patient uses for the policies they do set. As I say, 
>> accountability would increase if it's auditable in the same way as 
>> everything else. I'm familiar with an emergency first-responder 
>> system (firefighters and the like) put in place by a telco, where 
>> they're using identity claims that need to be part of a trust 
>> framework. The same could be used here, with policies set by the AS and
agreed to through the Ts & Cs.
>>
>>
>> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging 
>> Technology Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | 
>> Twitter:
>> @xmlgrrl
>>
>> On Tue, Feb 28, 2017 at 6:42 PM, Ioana Singureanu < 
>> ioana.singureanu at gmail.com> wrote:
>>
>>> Hi Eve:
>>>
>>> Just a clarification: emergency access (aka "break the glass") is 
>>> not an exception but rather type authorization policy but that that 
>>> cannot be modulated by patient through a consent. HIEs implement the 
>>> "break the glass" policy *explicitly *along with other policies.
>>> It's not an exception, but just another policy. From an UMA 
>>> stand-point it's not a very interesting policy because the patient has
no input.
>>>
>>> Kind regards,
>>> Ioana
>>>
>>> On Tue, Feb 28, 2017 at 2:38 PM, Eve Maler <eve.maler at forgerock.com>
>>> wrote:
>>>
>>>> The interesting thing about having the HEART profile(s) cover this 
>>>> use case is that the sharing of the data goes from an exception 
>>>> basis to an in-band, auditable, patient-involved (yet still 
>>>> lightweight) basis, where the other parties know they're 
>>>> responsible for proving (later) that there was a legitimate reason 
>>>> for the access based on their trust of the requesting party's 
>>>> claims. Accountability can go way up, and access involves using the
"same technology stack as usual".
>>>>
>>>> This is as opposed to current practice; a study I saw a few years 
>>>> ago for a European country showed that ~70% of hospital record 
>>>> access in one case was exception-based vs. rule-based -- and that's 
>>>> in a provider-to-provider scenario. I bet no one is surprised.
>>>>
>>>> Eve (from my iPad)
>>>>
>>>> On Feb 28, 2017, at 8:05 AM, Ioana Singureanu < 
>>>> ioana.singureanu at gmail.com> wrote:
>>>>
>>>> HI Nancy et al;
>>>>
>>>>
>>>> For patient safety, theUMA policy would not be invoked in cases 
>>>> when the user/initiator asserts the purpose of the request is
"emergency"
>>>> (rather "treatment" or "research").   For simplicity, we could assume
that
>>>> any consent or UMA policy will never refer to"emergency treatment" or
"ER"
>>>> because it simply does not matter in those cases.
>>>>
>>>> As a use cases, it may be a useful to address "emergency" but from 
>>>> an information flow it's trivial, the UMA would be disregarded. If 
>>>> the client is authorized, they will get *all *the data requested 
>>>> even if it's restricted.
>>>>
>>>> Cheers,
>>>> Ioana Singureanu
>>>>
>>>>
>>>> On Mon, Feb 27, 2017 at 7:36 PM, Nancy Lush <nlush at lgisoftware.com>
>>>> wrote:
>>>>
>>>>> Re:  But I also wonder if, in practice, there will be other true 
>>>>> role-based claims that would supplant the er/btg claim in practice.
>>>>>
>>>>> Good thought.  I had a problem using er for Emergency Responder as 
>>>>> I always think of the ER as Emergency Room.  Granted, they may 
>>>>> both need to BTG, but the Emergency Room role is typically within 
>>>>> a hospital setting and the Emergency Responder may be a deputized 
>>>>> citizen.  I do believe that Emergency Responders represent a hole 
>>>>> in our interoperability use cases that need attention.  Will be 
>>>>> good to see Glen?s whitepaper and understand the issue more
holistically.
>>>>>
>>>>>
>>>>>
>>>>> Thanks Justin.
>>>>>
>>>>>
>>>>>
>>>>> -Nancy
>>>>>
>>>>>
>>>>>
>>>>> *From:* Openid-specs-heart [mailto:openid-specs-heart-bou 
>>>>> nces at lists.openid.net] *On Behalf Of *Eve Maler
>>>>> *Sent:* Monday, February 27, 2017 5:28 PM
>>>>> *To:* openid-specs-heart at lists.openid.net
>>>>> *Subject:* [Openid-specs-heart] Comments on the UMA+FHIR profile 
>>>>> (and one additional profile comment)
>>>>>
>>>>>
>>>>>
>>>>> Great stuff!
>>>>>
>>>>>
>>>>>
>>>>> UMA+FHIR profile:
>>>>>
>>>>>    - User-Managed Access should have a hyphen throughout.
>>>>>    - As you already noted, the "openid-heart-fhir-oauth2" needs to be
>>>>>    changed.
>>>>>    - Claim semantics: Make this their own section (keeping the
>>>>>    positioning at Sec 3 is fine), and make sure to register them in
the OIDC
>>>>>    JWT claims registry. We could have a separate section (what is
currently
>>>>>    the introduction to Sec 3) discussing Claims Presentation, but I'm
not sure
>>>>>    this is warranted. Instead, the intro to discussing claim semantics
could
>>>>>    make clear that claims MAY be pushed or interactively gathered. (We
haven't
>>>>>    yet defined any claim profiles for pushed claims, but we should
probably
>>>>>    consider this: OIDC, I assume?)
>>>>>    - src claim: I wasn't sure if this would keep the same name, but
>>>>>    it should probably be "licensing" (or "accreditation")
"*authority*"
>>>>>    (rather than "board") to be a bit more generic.
>>>>>    - Food for thought: For the same reason that "airplane mode" is an
>>>>>    awkward name for turning off cell signal reception on your mobile
device --
>>>>>    it's too specific -- maybe the "er" claim should be called "btg" to
match
>>>>>    the scope name. But I also wonder if, in practice, there will be
other true
>>>>>    role-based claims that would supplant the er/btg claim in practice.
In
>>>>>    which case, Sec 4.1 could simply have a SHOULD or MUST around
enabling the
>>>>>    resource owner to audit the specific "btg"-related policies in
place along
>>>>>    with making any access ultimately granted auditable and available
to the
>>>>>    resource owner, etc.
>>>>>    - In UMA2, we've learned that the RS should document its pattern
>>>>>    of permission requests ("registrations"), and this may be relevant
for
>>>>>    profiling UMA1 as well. It would help the client know what sort of
stuff it
>>>>>    may be getting in its RPT.
>>>>>    - in Section 4: s/implementors/implementers/
>>>>>
>>>>>
>>>>>
>>>>> UMA profile:
>>>>>
>>>>>    - TTL of the PAT: The advice given is generic, referring to the
>>>>>    OAuth profile. But the PAT specifically needs to be used in an
"offline"
>>>>>    (asynchronous) way most of the time (on client access attempts) and
for
>>>>>    most use cases (when the requesting party isn't the same as the
resource
>>>>>    owner). Should we say something specific about this? The UMA
Implementers'
>>>>>    Guide does
>>>>>
<http://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Gui
de?src=contextnavchildmode#UMAImplementer'sGuide-RO-offlineEnsuringAsynchron
ousResourceServerAccesstoanAuthorizationServer>
>>>>>    .
>>>>>
>>>>>
>>>>> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging 
>>>>> Technology Cell +1 425.345.6756 <(425)%20345-6756> | Skype: 
>>>>> xmlgrrl | Twitter:
>>>>> @xmlgrrl
>>>>>
>>>>> _______________________________________________
>>>>> Openid-specs-heart mailing list
>>>>> Openid-specs-heart at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>    Ioana Singureanu
>>>>    Eversolve, LLC
>>>>    T: 603 548 5640 <(603)%20548-5640>
>>>>
>>>>
>>>
>>>
>>> --
>>>    Ioana Singureanu
>>>    Eversolve, LLC
>>>    T: 603 548 5640 <(603)%20548-5640>
>>>
>>
>>
>
>
> --
>    Ioana Singureanu
>    Eversolve, LLC
>    T: 603 548 5640 <(603)%20548-5640>
>
> _______________________________________________
> 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/20170301/e
59e13ec/attachment-0001.html>

------------------------------

Message: 4
Date: Wed, 1 Mar 2017 15:11:22 -0500
From: Adrian Gropper <agropper at healthurl.com>
To: John Moehrke <johnmoehrke at gmail.com>
Cc: Ioana Singureanu <ioana.singureanu at gmail.com>, HEART List
	<openid-specs-heart at lists.openid.net>
Subject: Re: [Openid-specs-heart] Comments on the UMA+FHIR profile
	(and one additional profile comment)
Message-ID:
	<CANYRo8gk_4yeH3rGwiQ2J1BS-UEknq1FFNO3uwjOW7ZfCKyTZg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I'm confused. (surprise!)

I agree with John "The important part is that UMA be engaged all the time."
because no matter how we treat emergencies, transparency is essential.

What confuses me is that a medical emergency override requires the RS, not
the AS, to authenticate the claims of the Requesting Party. The whole point
of an override is to ignore the decision of the AS. That puts the
responsibility for trust elevation with the RS. This seems completely
out-of-band from UMA with the only reasonable enhancement in HEART of a
notification to the UMA AS that something unusual happened at the RS.

Adrian

On Wed, Mar 1, 2017 at 3:00 PM, John Moehrke <johnmoehrke at gmail.com> wrote:

> I have a different 'policy' than the one Ioana outlines.
>
> First we need to get good clarity. "Emergency Department" is not the 
> same thing as Break-Glass (aka Medical-Emergency-Override). Where the 
> these Break-Glass accesses might happen more often from the Emergency 
> Department, but normal access from the emergency department would 
> be... "normal"... The people who work in the Emergency Room carry 
> structural and functional roles that represent the job the are 
> performing; those 'roles' usually enable a high privilege access.
>
> Break-Glass is a case where an authorized individual is enabled to 
> request privilege elevation. That privilege elevation is not absolute. 
> This is where Ioana and I differ. I am willing to allow discussion of 
> a UMA policy that mediates this privilege elevation. Indeed UMA might 
> be the arbitrator of who is allowed to request break-glass; or what 
> settings allow it. There are cases where patients really want no 
> access by specific individuals; even if it means pain/suffering/death 
> to the patient. It is their right to declare these policies.
>
> The important part is that UMA be engaged at all time.
>
> That said, there are medical-practice issues with this model. (as well 
> as operational reliability and availability).
>
> John
>
> John Moehrke
> Principal Engineering Architect: Standards - Interoperability, 
> Privacy, and Security CyberPrivacy ? Enabling authorized 
> communications while respecting Privacy M +1 920-564-2067 
> <(920)%20564-2067> JohnMoehrke at gmail.com 
> https://www.linkedin.com/in/johnmoehrke
> https://healthcaresecprivacy.blogspot.com
> "Quis custodiet ipsos custodes?" ("Who watches the watchers?")
>
> On Tue, Feb 28, 2017 at 11:43 PM, Ioana Singureanu < 
> ioana.singureanu at gmail.com> wrote:
>
>> Indeed...We already have a policy that mandates that we auditing all 
>> "disclosure" events regardless of purpose (aka "accounting for 
>> disclosure"). If an initiator asserts "emergency", "treatment",  or 
>> "research"...  we have to record who, when, and what information was
shared.
>>
>> Cheers,
>> Ioana
>>
>> On Tue, Feb 28, 2017 at 11:08 PM, Eve Maler <eve.maler at forgerock.com>
>> wrote:
>>
>>> Okay. But it could be accounted for by making it visible in the same 
>>> system the patient uses for the policies they do set. As I say, 
>>> accountability would increase if it's auditable in the same way as 
>>> everything else. I'm familiar with an emergency first-responder 
>>> system (firefighters and the like) put in place by a telco, where 
>>> they're using identity claims that need to be part of a trust 
>>> framework. The same could be used here, with policies set by the AS and
agreed to through the Ts & Cs.
>>>
>>>
>>> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging 
>>> Technology Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl 
>>> | Twitter:
>>> @xmlgrrl
>>>
>>> On Tue, Feb 28, 2017 at 6:42 PM, Ioana Singureanu < 
>>> ioana.singureanu at gmail.com> wrote:
>>>
>>>> Hi Eve:
>>>>
>>>> Just a clarification: emergency access (aka "break the glass") is 
>>>> not an exception but rather type authorization policy but that that 
>>>> cannot be modulated by patient through a consent. HIEs implement 
>>>> the "break the glass" policy *explicitly *along with other policies.
>>>> It's not an exception, but just another policy. From an UMA 
>>>> stand-point it's not a very interesting policy because the patient has
no input.
>>>>
>>>> Kind regards,
>>>> Ioana
>>>>
>>>> On Tue, Feb 28, 2017 at 2:38 PM, Eve Maler 
>>>> <eve.maler at forgerock.com>
>>>> wrote:
>>>>
>>>>> The interesting thing about having the HEART profile(s) cover this 
>>>>> use case is that the sharing of the data goes from an exception 
>>>>> basis to an in-band, auditable, patient-involved (yet still 
>>>>> lightweight) basis, where the other parties know they're 
>>>>> responsible for proving (later) that there was a legitimate reason 
>>>>> for the access based on their trust of the requesting party's 
>>>>> claims. Accountability can go way up, and access involves using the
"same technology stack as usual".
>>>>>
>>>>> This is as opposed to current practice; a study I saw a few years 
>>>>> ago for a European country showed that ~70% of hospital record 
>>>>> access in one case was exception-based vs. rule-based -- and 
>>>>> that's in a provider-to-provider scenario. I bet no one is surprised.
>>>>>
>>>>> Eve (from my iPad)
>>>>>
>>>>> On Feb 28, 2017, at 8:05 AM, Ioana Singureanu < 
>>>>> ioana.singureanu at gmail.com> wrote:
>>>>>
>>>>> HI Nancy et al;
>>>>>
>>>>>
>>>>> For patient safety, theUMA policy would not be invoked in cases 
>>>>> when the user/initiator asserts the purpose of the request is
"emergency"
>>>>> (rather "treatment" or "research").   For simplicity, we could assume
that
>>>>> any consent or UMA policy will never refer to"emergency treatment" or
"ER"
>>>>> because it simply does not matter in those cases.
>>>>>
>>>>> As a use cases, it may be a useful to address "emergency" but from 
>>>>> an information flow it's trivial, the UMA would be disregarded. If 
>>>>> the client is authorized, they will get *all *the data requested 
>>>>> even if it's restricted.
>>>>>
>>>>> Cheers,
>>>>> Ioana Singureanu
>>>>>
>>>>>
>>>>> On Mon, Feb 27, 2017 at 7:36 PM, Nancy Lush 
>>>>> <nlush at lgisoftware.com>
>>>>> wrote:
>>>>>
>>>>>> Re:  But I also wonder if, in practice, there will be other true 
>>>>>> role-based claims that would supplant the er/btg claim in practice.
>>>>>>
>>>>>> Good thought.  I had a problem using er for Emergency Responder 
>>>>>> as I always think of the ER as Emergency Room.  Granted, they may 
>>>>>> both need to BTG, but the Emergency Room role is typically within 
>>>>>> a hospital setting and the Emergency Responder may be a deputized 
>>>>>> citizen.  I do believe that Emergency Responders represent a hole 
>>>>>> in our interoperability use cases that need attention.  Will be 
>>>>>> good to see Glen?s whitepaper and understand the issue more
holistically.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks Justin.
>>>>>>
>>>>>>
>>>>>>
>>>>>> -Nancy
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Openid-specs-heart [mailto:openid-specs-heart-bou 
>>>>>> nces at lists.openid.net] *On Behalf Of *Eve Maler
>>>>>> *Sent:* Monday, February 27, 2017 5:28 PM
>>>>>> *To:* openid-specs-heart at lists.openid.net
>>>>>> *Subject:* [Openid-specs-heart] Comments on the UMA+FHIR profile 
>>>>>> (and one additional profile comment)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Great stuff!
>>>>>>
>>>>>>
>>>>>>
>>>>>> UMA+FHIR profile:
>>>>>>
>>>>>>    - User-Managed Access should have a hyphen throughout.
>>>>>>    - As you already noted, the "openid-heart-fhir-oauth2" needs to
>>>>>>    be changed.
>>>>>>    - Claim semantics: Make this their own section (keeping the
>>>>>>    positioning at Sec 3 is fine), and make sure to register them in
the OIDC
>>>>>>    JWT claims registry. We could have a separate section (what is
currently
>>>>>>    the introduction to Sec 3) discussing Claims Presentation, but I'm
not sure
>>>>>>    this is warranted. Instead, the intro to discussing claim
semantics could
>>>>>>    make clear that claims MAY be pushed or interactively gathered.
(We haven't
>>>>>>    yet defined any claim profiles for pushed claims, but we should
probably
>>>>>>    consider this: OIDC, I assume?)
>>>>>>    - src claim: I wasn't sure if this would keep the same name, but
>>>>>>    it should probably be "licensing" (or "accreditation") "
>>>>>>    *authority*" (rather than "board") to be a bit more generic.
>>>>>>    - Food for thought: For the same reason that "airplane mode" is
>>>>>>    an awkward name for turning off cell signal reception on your
mobile device
>>>>>>    -- it's too specific -- maybe the "er" claim should be called
"btg" to
>>>>>>    match the scope name. But I also wonder if, in practice, there
will be
>>>>>>    other true role-based claims that would supplant the er/btg claim
in
>>>>>>    practice. In which case, Sec 4.1 could simply have a SHOULD or
MUST around
>>>>>>    enabling the resource owner to audit the specific "btg"-related
policies in
>>>>>>    place along with making any access ultimately granted auditable
and
>>>>>>    available to the resource owner, etc.
>>>>>>    - In UMA2, we've learned that the RS should document its pattern
>>>>>>    of permission requests ("registrations"), and this may be relevant
for
>>>>>>    profiling UMA1 as well. It would help the client know what sort of
stuff it
>>>>>>    may be getting in its RPT.
>>>>>>    - in Section 4: s/implementors/implementers/
>>>>>>
>>>>>>
>>>>>>
>>>>>> UMA profile:
>>>>>>
>>>>>>    - TTL of the PAT: The advice given is generic, referring to the
>>>>>>    OAuth profile. But the PAT specifically needs to be used in an
"offline"
>>>>>>    (asynchronous) way most of the time (on client access attempts)
and for
>>>>>>    most use cases (when the requesting party isn't the same as the
resource
>>>>>>    owner). Should we say something specific about this? The UMA
Implementers'
>>>>>>    Guide does
>>>>>>
<http://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Gui
de?src=contextnavchildmode#UMAImplementer'sGuide-RO-offlineEnsuringAsynchron
ousResourceServerAccesstoanAuthorizationServer>
>>>>>>    .
>>>>>>
>>>>>>
>>>>>> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging 
>>>>>> Technology Cell +1 425.345.6756 <(425)%20345-6756> | Skype: 
>>>>>> xmlgrrl | Twitter:
>>>>>> @xmlgrrl
>>>>>>
>>>>>> _______________________________________________
>>>>>> Openid-specs-heart mailing list
>>>>>> Openid-specs-heart at lists.openid.net
>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>    Ioana Singureanu
>>>>>    Eversolve, LLC
>>>>>    T: 603 548 5640 <(603)%20548-5640>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>    Ioana Singureanu
>>>>    Eversolve, LLC
>>>>    T: 603 548 5640 <(603)%20548-5640>
>>>>
>>>
>>>
>>
>>
>> --
>>    Ioana Singureanu
>>    Eversolve, LLC
>>    T: 603 548 5640 <(603)%20548-5640>
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>
> _______________________________________________
> 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/20170301/4
284c0f2/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-heart


------------------------------

End of Openid-specs-heart Digest, Vol 112, Issue 4
**************************************************




More information about the Openid-specs-heart mailing list