Audit logs to support legal enforceability

[xmlgrrl]

Adapted from the 2012-08-01 ad hoc meeting notes:

We want to make UMA legally enforceable. How can the identity of Bob (the requesting party) get bound to any self-asserted claim he might make? If additional claims get collected in the "same session", you could, e.g., bind bob@gmail.com to the promise. Otherwise the consent is pretty weak, the same as today's browse-wrap. Server logs are going to be needed if we're to determine what obligations were agreed to. There's also a need to bind a persistent representation of the resource to this agreement. At a minimum, logs need to link to some authoritative source.

Do we need additional elements in the core spec (e.g. the security considerations, digital signatures over some elements) and/or in the binding obligations doc (e.g. an obligation to accurately record and securely store interactions) to capture this?

Note that, if a dispute comes down to evidentiary artifacts, today's circumstances are not all that great either. A lot of times, sites don't preserve copies of relevant EULAs. So the bar is fairly low if we want to achieve at least as much enforceability as we have in today's web apps.

[xmlgrrl]

See http://www.eventedapi.org for a short spec governing how to do simple REST-style event notification. Combine it with JOSE signing and encryption to help the AM keep secure audit logs, thus supporting Binding Obligations goals?

[xmlgrrl]

Also see the FHIR SecurityEvent proposal: http://www.hl7.org/implement/standards/fhir/securityevent.html

[xmlgrrl]

Zhanna's spec text proposal sent in email for consideration on 2014-07-24 (this was discussed in UMA telecon 2014-07-17 http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2014-07-17 as well):

Hello,
As my AI (draft for the Audit spec) I would like to share some thoughts on the participants, audit record structure and auditable events.

The participants.
“Main” participants - RS and AS;
“If desired” - Client, PR and RO(?). As minimum they should have the ability to get audit_id;

Audit record.
Required (per MIT Kerberos experience and FHIR SecurityEvent):

• audit id (signed-by-AS JWT or alpha-numeric string. Non-modifiable id )
• type of event (e.g. permission problem)
• event category (e.g. RS processing)
• timestamp when event was logged;
• event outcome (is event reported on success of failure)
• ip_address/url of the “host” and the “originator"
• type of source where event originated (e.g. Client)
• data life-cycle for the participant object;
• permission ticket (if applicable)
  Events per Binding Obligations and core:
• resource_id;
• RO Access policies;
• Claims (vs identity, bind id to claims);
• agreed-to obligations;
• scopes and permissions: what permissions host is looking for, “hoping” permissions,..;
• full token status;
• skew between permissions validity and actual access;
• …
  Optional:
• role of user (i.e. admin, privileged, student/professor, patient/doctor);
• on failure, details of the error and possible fix (?);
• …

Your comments are very welcome and appreciated.

[xmlgrrl]

Agreed to backlog this.

[xmlgrrl]

This is related to the Consent Receipts/MVCR work, which is, in part, being taken up by the legal subgroup in current meetings. See #180.