[Openid-specs-ab] User Profile liveness

Anthony Nadalin tonynad at microsoft.com
Mon Feb 8 16:33:35 UTC 2016


Not sure it should be the default as this just increases the size and not sure how many will really use this.

-----Original Message-----
From: Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of John Bradley
Sent: Friday, February 5, 2016 12:06 PM
To: Justin Richer <jricher at mit.edu>
Cc: openid-specs-ab at lists.openid.net Ab <openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] User Profile liveness

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.
>>>> 
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fope
>>>> nid.net%2fspecs%2fopenid-connect-core-1_0.html%23StandardClaims&dat
>>>> a=01%7c01%7ctonynad%40microsoft.com%7ce47ec0e442e746b7558e08d32e67c
>>>> 9bd%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Qn6jaZOei9jupYAGJ9
>>>> kvJv7U%2bSlfmxLtPSEHT8beXKI%3d
>>>> 
>>>> 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 
>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2
>>>>>>>> flists.openid.net%2fmailman%2flistinfo%2fopenid-specs-ab&data=0
>>>>>>>> 1%7c01%7ctonynad%40microsoft.com%7ce47ec0e442e746b7558e08d32e67
>>>>>>>> c9bd%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=x1bSSFKG%2bfv
>>>>>>>> IlD7%2bouM2r3XTwTF2HqX5CUVzyDVZjNo%3d
>>>>>> _______________________________________________
>>>>>> Openid-specs-ab mailing list
>>>>>> Openid-specs-ab at lists.openid.net
>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fl
>>>>>> ists.openid.net%2fmailman%2flistinfo%2fopenid-specs-ab&data=01%7c
>>>>>> 01%7ctonynad%40microsoft.com%7ce47ec0e442e746b7558e08d32e67c9bd%7
>>>>>> c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=x1bSSFKG%2bfvIlD7%2bo
>>>>>> uM2r3XTwTF2HqX5CUVzyDVZjNo%3d
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fli
>>>>> sts.openid.net%2fmailman%2flistinfo%2fopenid-specs-ab&data=01%7c01
>>>>> %7ctonynad%40microsoft.com%7ce47ec0e442e746b7558e08d32e67c9bd%7c72
>>>>> f988bf86f141af91ab2d7cd011db47%7c1&sdata=x1bSSFKG%2bfvIlD7%2bouM2r
>>>>> 3XTwTF2HqX5CUVzyDVZjNo%3d
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flis
>>>> ts.openid.net%2fmailman%2flistinfo%2fopenid-specs-ab&data=01%7c01%7
>>>> ctonynad%40microsoft.com%7ce47ec0e442e746b7558e08d32e67c9bd%7c72f98
>>>> 8bf86f141af91ab2d7cd011db47%7c1&sdata=x1bSSFKG%2bfvIlD7%2bouM2r3XTw
>>>> TF2HqX5CUVzyDVZjNo%3d
>>> 
>>> 
>> 
>> --
>> Vladimir Dzhuvinov
>> 
>> 
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.
> openid.net%2fmailman%2flistinfo%2fopenid-specs-ab&data=01%7c01%7ctonyn
> ad%40microsoft.com%7ce47ec0e442e746b7558e08d32e67c9bd%7c72f988bf86f141
> af91ab2d7cd011db47%7c1&sdata=x1bSSFKG%2bfvIlD7%2bouM2r3XTwTF2HqX5CUVzy
> DVZjNo%3d

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.openid.net%2fmailman%2flistinfo%2fopenid-specs-ab&data=01%7c01%7ctonynad%40microsoft.com%7ce47ec0e442e746b7558e08d32e67c9bd%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=x1bSSFKG%2bfvIlD7%2bouM2r3XTwTF2HqX5CUVzyDVZjNo%3d


More information about the Openid-specs-ab mailing list