Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> the bank will know the client private keys

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.



>> 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.

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.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: