[Openid-specs-ab] User Profile liveness

Justin Richer jricher at mit.edu
Fri Feb 5 19:30:46 UTC 2016


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
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160205/796009e5/attachment-0001.asc>


More information about the Openid-specs-ab mailing list