[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