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

[Eve Maler]

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/20160829/08839ba0/attachment.html>