[Openid-specs-ab] User Profile liveness
vladimir at connect2id.com
Fri Feb 5 08:32:47 UTC 2016
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.
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:)
> 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
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3711 bytes
Desc: S/MIME Cryptographic Signature
More information about the Openid-specs-ab