[WG-UMA] Audit in UMA

sampo at synergetics.be sampo at synergetics.be
Mon Aug 18 16:23:11 CDT 2014

Zhanna Tsitkov <tsitkova at mit.edu> said:
> Hello,
> I would like to share with you a (very-rought) draft Audit in UMA,  Please, see the text  below.  What do you think about it?  Also, I was not sure what is the best/preferred  format to present it to the WG, so I hope it is OK that I  just put it in the text of the email.
> Thanks,
> Zhanna
> Audit in UMA

> This document introduces an audit ID (audit_id) – an identifier with the following properties:
> 1.     It is unique for a given UMA exchange;
> 2.     It stays unchanged at any stage of the UMA exchange;
> 3.     It is generated as part of UMA processing, or is obtained from the upstream RS’s;
> 4.     It is protected against data tampering;
> 5.     It is available to all participants of the UMA exchange to be recorded for their audit needs;
> 6.     It can be passed to downstream RS’s.
> Section 1. Audit ID
> The audit identifier can be an (random) alphanumeric string, or a JSON structure.
> The uniqueness of the audit id is important especially in the cases when audit logs are processed dynamically.  Since randomizers on Clients are commonly weaker and less collision-resistant when compared to AS randomizers, in most environments, it should be the responsibility of AS to generate a high quality “strong” audit id.  However, it should be allowed for the Client to have its own audit id’s for the internal book-keeping.  This identifier can be passed to the authorization server as part of the initial request and AS should include it in the reply messages together with the “strong” AS-selected audit id.
> AS may adopt any audit identifier coming from the Client as a “strong” audit ID if it believes that it is a high quality identifier.

Uniqueness of audit_id can be poison to privacy, see more below.

> Section 3. Audit log parameters
> It is considered a good practice to keep the audit log concise. Overloading logs with unnecessary information comes with the burden of extra storage allocation and protection, and less effective information processing (both time-wise and resource-wise).

While the log itself may be concise, all the necessary proof needs
to be kept around in case of investigation. Thus all digitally signed
messages should be archived so that the digital signatures can be
validated upon investigation. The purpose of the log is mainly to
be a summary that contains pointers to all the fundamental evidence.

Upon investigation, the fundamental evidence is subpoenaed. The
accurate nature of the references in the audit log will allow
a very narrow subpoena to be drafted and thus it is more likely
that a judge would agree to it as the risk of collateral damage
from overbroad confiscation is reduced.

> The audit implementers have the opportunity to customize audit logs by extending auditable parameters and events, and making audit logging configurable.

Not sure if configurability is such a good thing here. All the legally
necessary stuff must appear for the log to be worth anything and why
would we want varying log schemas (or log formats for that matter).
At least some minimum necessary set should be mandatory.

> Section 4. Event selection
> In general, all AS-RS , Client-RS, Client-AS interactions, successful or not, should be recorded in the audit log files. This includes:
> - Permission requests;
> - Token issuance;
> - Resource Set registration;
> - Token introspection.

Any transaction should be logged on both sides so that the notes can
be compared.

> Section 5. Audit vs privacy
> In some cases it becomes desirable to protect the real identity
> of the user from the exposure in the audit logs.  It can be
> governed by policy settings on AS or RS.  The user identities
> can be completely omitted from the logs and some pseudonyms
> can be used in lieu of real names.  In this case the AS or RS,
> respectively, should support some table that matches the RO or
> RP to their pseudonyms.

Audit is necessarily a tradeoff between privacy and governability.
The audit_id has the danger of becoming correlation handle that
allows entities, that have received pairwise pseudonyms, to correlate
them, thus compromising the privacy protection afforded by pairwise

It is very important to make analysis of the correlation risks and
to whom they propagate. For example, if audit_id is public key
encrypted, separately for each entity, and audit records are
only ever held or archived in users Personal Data Store, it could
be argued that the correlation risk has been mitigated because only
the user himself can correlate. Of course, this would mean that
user's collaboration is needed in any forensic investigation.

If, however, some other party may see unencrypted audit_ids, then
existence of such correlating party should be disclosed to the


More information about the WG-UMA mailing list