[Openid-specs-ab] User Profile liveness

Justin Richer jricher at mit.edu
Fri Feb 5 18:05:02 UTC 2016


It's up to the AS to consider what an update *is* though. HTTP Cache 
semantics can't tell the RP that something was updated since it last 
cared to check, unless it checks again. You could do HEAD (if the server 
allows it) but that's a round trip and not worth it for the relatively 
small payload of userinfo.

  -- Justin

On 2/5/2016 11:43 AM, George Fletcher wrote:
> If it's a caching mechanism, can we just use HTTP cache semantics as 
> issued by the OP at time of first retrieval of the data? I worry that 
> what an AS considers as an "update" will fluctuate substantially such 
> that how well the mechanism works will be diluted unless some criteria 
> can be set around what constitutes an "update":)
>
> Thanks,
> George
>
> On 2/5/16 8:45 AM, Justin Richer wrote:
>> Right, the mechanism is already in the protocol, but it's awkward to 
>> process (not every client or idp implements "claims", which is fairly 
>> complex to support in full). I was proposing the stance of including 
>> it by default and checking for it by default for what is effectively 
>> cache management.
>>
>>  -- Justin
>>
>> On 2/5/2016 3:32 AM, Vladimir Dzhuvinov wrote:
>>> Haven't we already got the updated_at claim for this purpose? RPs 
>>> can request updated_at to be included in the ID token via the 
>>> "claims" param.
>>>
>>> http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims
>>>
>>> On 04/02/16 23:42, George Fletcher wrote:
>>>> I like the idea but it feels like whether it's useful or not is 
>>>> completely dependent on the implementation of the AS. If the AS 
>>>> identity record has a "last accessed" field that I update every 
>>>> time the user authenticates or SSO's then the 'last_updated' value 
>>>> will almost always be different than what the client has. However, 
>>>> if the identity record just has username and email address then the 
>>>> 'last_updated' value would rarely change and it would be very 
>>>> useful to the clients. Of course real practice is somewhere in the 
>>>> middle:)
>>>>
>>>> Thanks,
>>>> George
>>>>
>>>> On 2/4/16 1:29 PM, Justin Richer wrote:
>>>>> You can still do all of these other things below as well, this 
>>>>> doesn’t preclude them. For most, making the call at all is the 
>>>>> trouble, not the size of the response. If I can avoid the network 
>>>>> roundtrip then we’re in better shape.
>>>>>
>>>>> It’s a very small delta to the ID token.
>>>>>
>>>>>   — Justin
>>>>>
>>>>>> On Feb 4, 2016, at 11:27 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>>>>>
>>>>>> I see why you might want to do that.
>>>>>>
>>>>>> That however release on the user being present to do an 
>>>>>> authentication.
>>>>>>
>>>>>> I would prefer to find a more REST like approach where the client 
>>>>>> can use its token to do a HEAD of the user-info endpoint to see 
>>>>>> if the resource has changed.
>>>>>>
>>>>>> That may well be harder to do in implementations however.
>>>>>>
>>>>>> Back channel calls are not that expensive compared to making all 
>>>>>> id_tokens larger.
>>>>>>
>>>>>> Is it the size of the response that bothers people, or checking 
>>>>>> at all?
>>>>>>
>>>>>> We could just add a last changed claim to user_info so that the 
>>>>>> client would not need to process the response, but that probably 
>>>>>> doesn’t save much.
>>>>>>
>>>>>> The concern with adding it to the id_token is that people may add 
>>>>>> it by default, and it not be used by clients.
>>>>>>
>>>>>> If we add it it should be explicitly asked for as a scope.
>>>>>>
>>>>>> John B.
>>>>>>
>>>>>>
>>>>>>> On Feb 4, 2016, at 1:05 PM, Justin Richer <jricher at MIT.EDU> wrote:
>>>>>>>
>>>>>>> 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
>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
> -- 
> Chief Architect
> Identity Services Engineering     Work:george.fletcher at teamaol.com
> AOL Inc.                          AIM:  gffletch
> Mobile: +1-703-462-3494           Twitter:http://twitter.com/gffletch
> Office: +1-703-265-2544           Photos:http://georgefletcher.photography

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


More information about the Openid-specs-ab mailing list