A blockchain related technology is overkill, you just need forward integrity: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.111...
But you're still protected against transactions alleged to have occurred before your last real transaction or, equivalently, you're guaranteed to (in theory) notice the fraud the next time you try to do a genuine transaction.
No one knows the private key other than the creator, in this case the developer.
> Direct support for non-repudiable signatures on the transactions themselves. Unless I'm misunderstanding what the client certs are doing in this protocol, TAuth seems to give non-repudiation on the session setup but not on the transactions themselves.
There is nothing stopping the API provider enforcing layer 7 signatures too, it's an application concern. The same private key can be used to compute those signatures or as X.509 certs can embed arbitrary public keys, you can choose another one for transaction signatures.
> Is that actually correct as written or did you mean "to a given user"?
The first version of TAuth is for Server to server apps. In this case it means developer. I will clarify that in the post. Thanks.
So what, exactly, is non-repudiable? If I go to a highly enlightened court wielding a signature, what can I prove to that court? That my app really did connect to your server at the time I allege it did? This seems weak to me.
1. The client (or the device holding the authentication token, or the app, etc) should be able to maintain (on its own storage!) an audit log of all transactions it has authorized, that log should be cryptographically verifiable to be append-only (think blockchain but without all the Bitcoin connotations), and the server should store audit log hashes and verify that they were only ever appended to. And the server should send a non-repudiable confirmation of this back to the client.
Why? If someone compromises the bank or the bank-issued credentials (it seems quite likely that, in at least one implementation, the bank will know the client private keys), the client should be able to give strong evidence that they did not initiate a given transaction by showing (a) their audit log that does not contain that transaction and (b) the server's signature on that audit log.
2. Direct support for non-repudiable signatures on the transactions themselves. Unless I'm misunderstanding what the client certs are doing in this protocol, TAuth seems to give non-repudiation on the session setup but not on the transactions themselves. Did I read it wrong?
3. An obvious place where an HSM fits in.
How does TAuth stack up here?
Also, there's a very strange statement on the website:
> to unimpeachably attribute a request to a given developer. In cryptography this is known as non-repudiation.
Is that actually correct as written or did you mean "to a given user"?