<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi,<div><br></div><div>Connect dosen't specify any format for access tokens, those are implementation specific. </div><div><br></div><div>There has been discussion around the need for a session_id to allow backchannel messages to reference particular sessions. </div><div><br></div><div>At the moment the closes thing to that is nonce which is set by the Client and returned in the id_token. It is however opaque to the AS so probably not suitable.</div><div><br></div><div>Is a ssession_id more of what you are looking for? The jti is intended to stop token replay and will be changed if the id_token is refreshed.</div><div><br></div><div>John B.</div><div><br><div><div>On Aug 5, 2014, at 5:20 PM, Zhanna Tsitkov <<a href="mailto:tsitkova@MIT.EDU">tsitkova@MIT.EDU</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<span style="font-size: 12px;"><font face="Cambria">Hello,</font></span>
<div><span style="font-size: 12px;"><font face="Cambria">I am looking at introducing audit feature to OIDC. More specifically, I would like to have an Audit_id - an identifier that is used for audit purposes and can be traced to the particular participant
of the OIDC session. Audit_id should stay unchanged and be available to all end-to-end participants of the exchange. Once generated, the audit_id can be recorded as part of audit logs at any stage of the exchange and, ideally, be available to downstream RS’s
(or somehow deduced/back-traced ).</font></span></div>
<div><span style="font-size: 12px;"><font face="Cambria">Audit_id can be either an alpha-numeric string (either randomly generated or something in lines with "audit_id=sub+auth_time+jti") or some json structure. Audit_id can be generated and signed by OP upon
successful end-user authorization and then carried as an optional parameter in the further processing. Alternatively, as Justin Richer has suggested, one can use access and ID token jti’s as "audit id" and have a table (at the AS) of relationships indexed
by token identifier. </font></span></div>
<div><span style="font-size: 12px;"><font face="Cambria">The data of interest for audit includes permissions, policies, scopes, claims, authZ, authN related information. For example, it can be used by government for audit purposes (banks, government agencies),
or for audit log dynamic processing for the fast violation response systems, revocations etc. The relevant Common Criteria document can be found here: <a href="http://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R4.pdf"><span style="color: windowtext;">http://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R4.pdf</span></a> </font></span></div>
<div><span style="font-size: 12px;"><font face="Cambria"><br>
</font></span></div>
<div><span style="font-size: 12px;"><font face="Cambria">Your input and comments are appreciated.<br>
<br>
Thanks,<br>
Zhanna</font></span></div>
</div>
_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></blockquote></div><br></div></body></html>