[Openid-specs-ab] User Profile liveness

Fri Feb 5 13:45:24 UTC 2016

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

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