[Openid-specs-ab] audit in OIDC

Zhanna Tsitkov tsitkova at MIT.EDU
Thu Aug 7 20:31:59 UTC 2014


Hello Nat,
I think it is a reasonable starting point: first of all, nothing-really-interesting-has-happened-yet, and, secondly, as you correctly pointed, the client’s randomizers are (commonly?) less trustworthy ( = less conflict-resistant) than ones on AS.
On the other hand, I see that there are environments where audit logs are needed to track the exchange from its very beginning.  One of the possible approaches would be to allow, say, client, to have its  own audit identifier, and  be ready to process it on AS (record it in some “matching” table on AS, or just log it, or somehow incorporate it into AS-made audit identifier).  Still, it would be AS's responsibility to select/generate high-quality audit identifier to pass it along to all participants.

Thanks,
Zhanna

On Aug 7, 2014, at 3:35 PM, Nat Sakimura <sakimura at gmail.com<mailto:sakimura at gmail.com>> wrote:

Hi Zhanna,

Starting from jti means that you cannot track the failed authn/authz requests.
Would that be OK?
If you want to track from the very beginning, then it has to start from the client/RP's authn request, I suppose, but the randoms generated by a client tend to be quite untrustworthy in practice. So, we may need to have some endpoint in the OP to give out the transacion id. (BTW, mixi, one of the largest Japanese social game vendor extended Connect and does it.)

Nat


2014-08-06 6:20 GMT+09:00 Zhanna Tsitkov <tsitkova at mit.edu<mailto:tsitkova at mit.edu>>:
Hello,
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 ).
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.
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: http://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R4.pdf

Your input and comments are appreciated.

Thanks,
Zhanna

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140807/f308a1c2/attachment.html>


More information about the Openid-specs-ab mailing list