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

Thomas Rieneck THRE at sundhedsdata.dk
Tue Aug 30 06:14:02 UTC 2016


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<mailto: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<mailto: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<mailto: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<mailto: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/f0dcc73b/attachment-0001.html>


More information about the Openid-specs-heart mailing list