<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
-- Justin<br>
<br>
<div class="moz-cite-prefix">On 2/5/2016 3:32 AM, Vladimir Dzhuvinov
wrote:<br>
</div>
<blockquote cite="mid:56B45E2F.2080206@connect2id.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
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.<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims">http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims</a><br>
<br>
<div class="moz-cite-prefix">On 04/02/16 23:42, George Fletcher
wrote:<br>
</div>
<blockquote cite="mid:56B3C5AF.70906@aol.com" type="cite">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:) <br>
<br>
Thanks, <br>
George <br>
<br>
On 2/4/16 1:29 PM, Justin Richer wrote: <br>
<blockquote type="cite">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. <br>
<br>
It’s a very small delta to the ID token. <br>
<br>
— Justin <br>
<br>
<blockquote type="cite">On Feb 4, 2016, at 11:27 AM, John
Bradley <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:ve7jtb@ve7jtb.com"><ve7jtb@ve7jtb.com></a>
wrote: <br>
<br>
I see why you might want to do that. <br>
<br>
That however release on the user being present to do an
authentication. <br>
<br>
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. <br>
<br>
That may well be harder to do in implementations however. <br>
<br>
Back channel calls are not that expensive compared to making
all id_tokens larger. <br>
<br>
Is it the size of the response that bothers people, or
checking at all? <br>
<br>
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. <br>
<br>
The concern with adding it to the id_token is that people
may add it by default, and it not be used by clients. <br>
<br>
If we add it it should be explicitly asked for as a scope. <br>
<br>
John B. <br>
<br>
<br>
<blockquote type="cite">On Feb 4, 2016, at 1:05 PM, Justin
Richer <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:jricher@MIT.EDU"><jricher@MIT.EDU></a>
wrote: <br>
<br>
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? <br>
<br>
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. <br>
<br>
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. <br>
<br>
— Justin <br>
_______________________________________________ <br>
Openid-specs-ab mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
<br>
</blockquote>
</blockquote>
_______________________________________________ <br>
Openid-specs-ab mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
<br>
</blockquote>
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</body>
</html>