[Openid-specs-ab] User Profile liveness

John Bradley ve7jtb at ve7jtb.com
Fri Feb 5 20:05:56 UTC 2016


I suspect it is something that some RP will want and others won’t care about.

Some schools of thought are that the client should only cache information for a short time and refetch it when needed to preserve privacy.

The principal pf data minimization.   Making this the default would seem to go against that.  (Yes I appreciate that almost no one is doing data minimization)

I would prefer it to be a option via client registration, or via a claim request.

Any client using it is going to need to be modified anyway so sending a claim request is not the end of the world. 

Servers to support it will also need to be modified.  

We have the claim so that is not a big deal.   The question is should it be the default.

John B.
> On Feb 5, 2016, at 4:30 PM, Justin Richer <jricher at mit.edu> wrote:
> 
> Nobody is suggesting a duplicate claim. I’m suggesting that we do exactly what you’re saying here and asking for feedback on the practice, if it would be useful for general RPs or not.
> 
> — Justin
> 
>> On Feb 5, 2016, at 2:28 PM, Vladimir Dzhuvinov <vladimir at connect2id.com> wrote:
>> 
>> I see. In that case why not reuse the existing claim, and just let
>> compliant OPs that are going to support this feature include it in
>> issued ID tokens? The suggestion has merit, I'm just not convinced it
>> requires a duplicate claim for that.
>> 
>> Vladimir
>> 
>> On 05/02/16 15:45, 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
>>> 
>>> 
>> 
>> --
>> Vladimir Dzhuvinov
>> 
>> 
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab



More information about the Openid-specs-ab mailing list