<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
It's up to the AS to consider what an update *is* though. HTTP Cache
semantics can't tell the RP that something was updated since it last
cared to check, unless it checks again. You could do HEAD (if the
server allows it) but that's a round trip and not worth it for the
relatively small payload of userinfo. <br>
<br>
-- Justin<br>
<br>
<div class="moz-cite-prefix">On 2/5/2016 11:43 AM, George Fletcher
wrote:<br>
</div>
<blockquote cite="mid:56B4D11C.6020505@aol.com" type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<font face="Helvetica, Arial, sans-serif">If it's a caching
mechanism, can we just use HTTP cache semantics as issued by the
OP at time of first retrieval of the data? I worry that what an
AS considers as an "update" will fluctuate substantially such
that how well the mechanism works will be diluted unless some
criteria can be set around what constitutes an "update":)<br>
<br>
Thanks,<br>
George<br>
</font><br>
<div class="moz-cite-prefix">On 2/5/16 8:45 AM, Justin Richer
wrote:<br>
</div>
<blockquote cite="mid:56B4A774.1010507@mit.edu" type="cite">
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"> 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 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>
<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>
<pre class="moz-signature" cols="72">--
Chief Architect
Identity Services Engineering Work: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:george.fletcher@teamaol.com">george.fletcher@teamaol.com</a>
AOL Inc. AIM: gffletch
Mobile: +1-703-462-3494 Twitter: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://twitter.com/gffletch">http://twitter.com/gffletch</a>
Office: +1-703-265-2544 Photos: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://georgefletcher.photography">http://georgefletcher.photography</a>
</pre>
</blockquote>
<br>
</body>
</html>