[Openid-specs-heart] Health Relationship Trust Profile for User Managed Access 1.0

[Eve Maler]

Indeed this is an opportunity for HEART, as a "sectoral" profile, to
provide just such guidance. There are actually some technical ways to
bridge a gap in access token validity (such as a "rolling" refresh
pattern), if we wish to consider/mention them. Beyond that, we could
consider the impacts at legal agreement levels (what's required if access
fails at a critical juncture for certain kinds of data?) and even UX and
extension spec levels if we see fit (asynchronous patient notifications?).


*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, Aug 29, 2016 at 11:14 PM, Thomas Rieneck <THRE at sundhedsdata.dk>
wrote:

> Well, to me it seems odd to omit clear operational guidance on how to
> handle the situation where the patient as Resource Owner doesn’t have a
> valid PAT and is not available for reauthorization.
>
> If some measure is needed here to circumvent proper authorization what is
> then left of the patients control of his or her data?
>
>
>
> Thomas Rieneck
>
>
>
> *Fra:* Eve Maler [mailto:eve.maler at forgerock.com]
> *Sendt:* 29. august 2016 20:57
> *Til:* Justin Richer <jricher at mit.edu>
> *Cc:* Thomas Rieneck <THRE at sundhedsdata.dk>; openid-specs-heart at lists.
> openid.net
> *Emne:* Re: [Openid-specs-heart] Health Relationship Trust Profile for
> User Managed Access 1.0
>
>
>
> In my personal experience, for whatever that's worth, even banks seem to
> have given up on everytime/daily required logins through mobile. It's
> possible to leverage a lot more silent contextual authentication cues of
> various sorts in more clever fashion now -- deep device fingerprinting,
> geofencing, etc. (This is why I think merely counting factors is getting
> more and more useless, particularly as the "out-of-band-ness" of some of
> the factors should be questioned.)
>
>
>
> Can we truly attach concise and effective guidance to a SHOULD when the
> authentication picture is so complex and changeable, or should we really
> provide a SHOULD at all here, vs. the guidance alone?
>
>
>
> And keep in mind that a PAT is a special case of an OAuth access token,
> since it's designed to be used by the UMA resource server in some "resource
> owner is offline" circumstances
> <http://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Guide?src=contextnavchildmode#UMAImplementer'sGuide-RO-offlineEnsuringAsynchronousResourceServerAccesstoanAuthorizationServer>:
> a) for resource set registration that's potentially asynchronous to when
> the resource owner does something (say, the API just got a new version) and
> b) at client-driven access attempt time, when the resource owner isn't
> around unless they also happen to be the requesting party. So needing to
> refresh it daily for *everyone else* to be able to use it when you're not
> around might be a big bummer.
>
>
>
> The advice of the UMA Implementer's Guide, linked above, is: "The
> authorization server thus needs to manage the issuance and expiration of
> the PAT and and [sic] any corresponding refresh token appropriately to
> ensure that the resource server has access when it needs it."
>
>
>
> *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 Sat, Aug 27, 2016 at 3:24 PM, Justin Richer <jricher at mit.edu> wrote:
>
> This is a recommendation, not a requirement, but better guidance might be
> warranted. The current text errs on the side of failing closed.
>
>
>
>  — Justin
>
>
>
> On Aug 26, 2016, at 4:55 AM, Thomas Rieneck <THRE at sundhedsdata.dk> wrote:
>
>
>
> Token Lifetimes for refresh tokens for PAT should not exceed 24 hours
> according to the above spec  – that implies that Resource Owners should
> authenticate every day for Requesting Parties being able to access their
> resources.
>
> If the patient is the Resource Owner that does not seem realistic.
>
>
>
> Best regards
>
> Thomas Rieneck
>
> Nationale Health Data Agency
>
> _______________________________________________
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160830/2b043f42/attachment.html>