[Openid-specs-ab] User Profile liveness

Justin Richer jricher at mit.edu
Thu Feb 4 18:28:47 UTC 2016


You can still do that. This is just a hint to tell you you might want to, you’re free to ignore it.

 — Justin

> On Feb 4, 2016, at 11:28 AM, Nat Sakimura <sakimura at gmail.com> wrote:
> 
> It is potentially useful, though in some other cases, the client may want to hit the Userinfo endpoint without user login just to see if the data is fresh. 
> Insurance companies tends to fall in this category. 
> 
> Best, 
> 
> Nat
> 
> 2016年2月5日(金) 1:05 Justin Richer <jricher at mit.edu <mailto:jricher at mit.edu>>:
> One of the good things in OIDC is the fact that the claims about a user are split between the ID Token (things that are needed for the authN transaction) and the user info endpoint (things that are needed for the profile and other functions of the app). Theoretically it cuts down on sending redundant and unchanging information with each authentication. However, the tension of whether and when an RP should pull from the IdP’s UserInfo Endpoint is an age old question of cache consistency. Should the RP call on each transaction? After a time out? When it really really wants to?
> 
> Anyway, I think there’s a simple way that the IdP can signal to the RP whether it’s worth pulling information. If the IdP always includes the “last_updated” claim in the ID token, the RP can decide whether its cache of UserInfo is fresh enough or not by doing a simple comparison on that value and its local cache. It’s coarse grained, because you don’t know if you care about whatever claim was updated or not, but it’s at least *some* signal that can be used inside an already existing structure.
> 
> We’re considering just implementing this in our server and client, but I’d like to see what others thought of this idea and if it would be worthwhile propagating this pattern. I feel it’s very low overhead in the ID Token for a potentially big benefit of live data and lower network traffic from the RP.
> 
>  — Justin
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab <http://lists.openid.net/mailman/listinfo/openid-specs-ab>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160204/dfeb1d89/attachment.html>


More information about the Openid-specs-ab mailing list