Hi Zhanna, thanks for sharing your thoughts with the OAuth group.
I have been wondering where this audit identifier should go. Are you talking about putting a new identifier into some protocol exchanges (and which messages) or are we talking about an implementation issue? Also, when you say you want to have a way to "track all OAuth exchanges" I am curious who should be able to do this tracking. OAuth, as you know, involves multiple independent parties. I am asking because of potential privacy concerns. Which part of the Common Criteria document do you believe is relevant to this specific aspect? I noticed that there is an audit section in there but it refers to a more general notion of audit that has little to do with the actual protocol interaction. Ciao Hannes On 08/20/2014 10:01 PM, Zhanna Tsitkov wrote: > Hello, > I would like to introduce a new feature to OAuth 2.0 - an Audit. The > ultimate goal would be to have some simple, well defined way to track > all exchanges under OAuth 2.0 umbrella, connect all end-to-end > participants for the audit purposes, so that audit logs could be > processed dynamically for the fast violation response, or analyzed for > the forensic purposes off-line. > My suggestion is to have a new audit identifier (audit id). It should be > unique and stay unchanged for a given exchange. It should be recorded > in all audit logs. It can be passed to and between different modules > and components of OAuth 2.0 > Audit identifier can be either alpha-numeric string or JSON structure. > It can be signed for the integrity protection, or even encrypted if > privacy is an issue. > Audit id can be generated at AS as a random string, or composed > following some rules. In addition, Clients and/or RSs can generate their > own audit identifiers for their own bookkeeping, and include them > in their requests. In this case all relevant communications should > include both AS generated audit identifier and Client’s and/or RS’s > (respectively) audit identifiers. > Generally, the data of interest include policies, > permissions, authorization and authentication information, etc and could > be used by government agencies, medical and banking institutions etc. > Please, see the relevant Common Criteria > document http://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R4.pdf > document. > Thanks, > Zhanna > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
