jot2re — Today at 20:12
For me the issue is more the whole concept that OAuth requires an Authorisation server, which in the Ethereum flow, will actually be the same conceptual entity as the user themself. The other issue. The other is that OAuth is actually an authorisation protocol and not directly an authentication protocol. The authentication aspects must be handled in the concrete usage, as is for example done in OpenID connect.
I had a discussion with @Nick-t yesterday on the same topic and thought that - using oath as-is without centralised confidential party is impossible, because oath is designed for using such a party. - the reason they want oauth is for developer adoption So we went for the idea of using Oauth's flow, format and terminology, but doing it in decentralised way. that should ease the developer adoption (the problem they initially wanted to address) and still 'based on Oauth'. Note that in this version we did not provide a solution that can use Oath the way the standard was written, and did not introduce a centralised confidential party, bot we Oauthed our way as much as possible. @Victor @RubberDucky @Nick-t feedback all very much needed because @Victor signals us to release today. Also I removed the cryptographic protocol because the old protocol wasn't designed with Oauth𝑖𝑛𝑒𝑠𝑠 in mind (with the refresh-key and access-key separation). Instead, I wrote that 'please trust we know our cryptography' and kept on a higher level.
jot2re — Today at 20:26
Ah, sorry, I didn't read all the thread to the end before starting to reply. I agree with Weiwu and Nick. But I do believe that including the cryptography (at least as an appendix) is a good idea. Especially also for the reviewers to be able to consider the efficiency of the approach so they see that we are not doing really expensive zk-snarks or anything like that.
jot2re — Today at 20:38
@weiwu @Nick-t I am not sure how exactly revocation would work. It currently seems to work under the assumption that the user has linked their session key with there Ethereum address. Which might be a fair assumption, but I think we should make make it explicit
Nick-t — Today at 21:22
To provide an idea around revocation - the wallet in the new design is used in place for the central auth server, what would you think if the user was in control of revocation of refresh tokens? For example, the user would have a disconnect option in their wallet UI which would revoke the wallet from re-issuing a new access token upon request. The wallet would know which websites it had issues access tokens to.
jot2re — Today at 21:24
@weiwu @Nick-t I have some more comments to the new description: Under Login it is described that the refresh key pair is derived from the server's challenge. This means that the server can brute-force the user's Ethereum address. Furthermore, if it succeeds, or if the user shares their address later one, it also mean that the server can derive the user's private refresh key and hence completely pretend to be the user towards itself. This might not be an issue but it means it can construct fake logs of user authentication. I suggest we keep the approach discussed of using BIP32 and derive the user's refresh keys based on the user's private Ethereum key, the server's domain and the server's challenge. At least in this case the server cannot create fake authentication requests on behalf of the user once it learns the user's Ethereum address. Although it will still be able to brute force the user's Ethereum address offline.
jot2re — Today at 21:34
So in this situation you assume the wallet can be synced across multiple devices, right? But I can still not see how things are then linked implicitly to the user's Ethereum key. Because as I understand it, the refresh key will be based on the website's domain, the user's Eth address and the website's initial challenge. So in this situation the user would only be able to revoke the session keys if it actually knows the challenge. So this would need to be synced to the user's wallet across devices. In this situation I also fail to see how a user's account is linked across multiple devices unless the user has shared their Eth address or ENS
@weiwu @RubberDucky feedbacks from ENS
jot2re — Today at 21:36
Okay, it sounds like they do really want the full OAuth approach. In that case we should have some sort of solution like EAuth, where a webserver is basically run locally in order to have this be the target of the HTTP redirect that is part of the OAUth flow