4 ms·

Why replace OAuth? That's an authorization protocol. Do you mean OpenId Connect? In any case, I strongly believe these things should be managed by user agents:

Why replace OAuth? That's an authorization protocol. Do you mean OpenId Connect? In any case, I strongly believe these things should be managed by user agents: https://www.w3.org/TR/webauthn/ https://www.w3.org/TR/webauthn/ While I understand the single master key way makes it trivial to manage multiple clients, it is a non-starter as far as I'm concerned since you cannot rotate it once you've used it as a credential on multiple services. And what about revocation? If you support neither rotation nor revocation, each credential must be independent or you are painting yourself into a corner.

homakov 9y ago
Check "change password" section for rotation of one profile to another. It's quite simple Why replace OAuth? because it sucks. It's stateful on the server, and it's security surface is bad. With SL you could sign a token for client=me provider=facebook scope=profile,photos,friends expire=3months. and all that would be stateless w/o any extra code on the server of identity provider. It is a huge step over OAuth code which is often full of holes (see Doorkeeper in Rails)
- arnarbi 9y ago
  An update operation is one part of a solution. Are passwords versioned? You will eventually get into a state on some client where you have changed the pwd N times since last talking to a particular server. Does that client have to keep around N passwords to be able to update it? That defeats the purpose of rotation, which is to fully retire an old key. As for your example, you can do exactly the same thing with OAuth client assertions: https://tools.ietf.org/html/rfc7521 https://tools.ietf.org/html/rfc7521 OAuth implementations being buggy is a valid point, but why wouldn't the same apply to SL or any authz protocol?
  - homakov 9y ago
    I can't understand first paragraph, especially "versioned" passwords. Every profile is result of generation, and you can change profile (manually or automatically) if you think it was compromised. With OAuth you add a lot of extra code in your app. Like storing client_id client_secret and you need grant dialogs etc. Have a look at this demo (any account with web version): https://securelogin.pw/#provider=http://facebook.com&client=http://locateMyFriends.com&scope=Share%3dFriends https://securelogin.pw/#provider=http://facebook.com&client=..., Locations With NO code any website could ask access to other provider. Little code on the server side needed. Granular permissions. Etc
    - arnarbi 9y ago
      With "versioned" passwords I mean a way to detect when a site hasn't been updated after a master password change. Presumably you need the old password to generate the old key, which is used to sign the change request. If you've changed your password multiple times since you last spoke with that website, how do you know which old password to use. You mention automation, which is good, but you may not be able to rely on it succeeding. Until every client website has responded to the change request, you must keep around or remember the old passwords. For automation you also have to store the list of websites you've registered with somewhere. Since your system works on multiple clients, that place has to be central. My point was that the protocol to "refresh" a website account with a new master pwd only solves part of the key rotation (=master password change) story. As for OAuth, I don't agree with you that it is onerous. Yes, client_id and secret are poor mechanisms, and better ones will emerge. But there are many cases where you absolutely want to authenticate the client (it might not always be the user's own browser) in addition to the user/grant.
      - homakov 9y ago
        That's what made me confused. There is no way to "change" password, only to create a new profile and migrate to it. And you can have many profiles at the same time (some with equal email). >For automation you also have to store the list of websites you've registered with somewhere. Since your system works on multiple clients, that place has to be central. The plan is: until we have 1000+ origins using the protocol, there will be a manual list of origins that will be tried for reset. After that, it will be sorted out with a central server and encrypted list of origins. Sounds good? > you absolutely want to authenticate the client (it might not always be the user's own browser) in addition to the user/grant Cool part is you still can. Provider can look at "client" the token was issued to, and reject if it does not match with some authorized Client record in the database. It's rather flexible for any scenario.

homakov 9y ago

Check "change password" section for rotation of one profile to another. It's quite simple Why replace OAuth? because it sucks. It's stateful on the server, and it's security surface is bad. With SL you could sign a token for client=me provider=facebook scope=profile,photos,friends expire=3months. and all that would be stateless w/o any extra code on the server of identity provider. It is a huge step over OAuth code which is often full of holes (see Doorkeeper in Rails)

arnarbi 9y ago
An update operation is one part of a solution. Are passwords versioned? You will eventually get into a state on some client where you have changed the pwd N times since last talking to a particular server. Does that client have to keep around N passwords to be able to update it? That defeats the purpose of rotation, which is to fully retire an old key. As for your example, you can do exactly the same thing with OAuth client assertions: https://tools.ietf.org/html/rfc7521 https://tools.ietf.org/html/rfc7521 OAuth implementations being buggy is a valid point, but why wouldn't the same apply to SL or any authz protocol?
- homakov 9y ago
  I can't understand first paragraph, especially "versioned" passwords. Every profile is result of generation, and you can change profile (manually or automatically) if you think it was compromised. With OAuth you add a lot of extra code in your app. Like storing client_id client_secret and you need grant dialogs etc. Have a look at this demo (any account with web version): https://securelogin.pw/#provider=http://facebook.com&client=http://locateMyFriends.com&scope=Share%3dFriends https://securelogin.pw/#provider=http://facebook.com&client=..., Locations With NO code any website could ask access to other provider. Little code on the server side needed. Granular permissions. Etc
  - arnarbi 9y ago
    With "versioned" passwords I mean a way to detect when a site hasn't been updated after a master password change. Presumably you need the old password to generate the old key, which is used to sign the change request. If you've changed your password multiple times since you last spoke with that website, how do you know which old password to use. You mention automation, which is good, but you may not be able to rely on it succeeding. Until every client website has responded to the change request, you must keep around or remember the old passwords. For automation you also have to store the list of websites you've registered with somewhere. Since your system works on multiple clients, that place has to be central. My point was that the protocol to "refresh" a website account with a new master pwd only solves part of the key rotation (=master password change) story. As for OAuth, I don't agree with you that it is onerous. Yes, client_id and secret are poor mechanisms, and better ones will emerge. But there are many cases where you absolutely want to authenticate the client (it might not always be the user's own browser) in addition to the user/grant.
    - homakov 9y ago
      That's what made me confused. There is no way to "change" password, only to create a new profile and migrate to it. And you can have many profiles at the same time (some with equal email). >For automation you also have to store the list of websites you've registered with somewhere. Since your system works on multiple clients, that place has to be central. The plan is: until we have 1000+ origins using the protocol, there will be a manual list of origins that will be tried for reset. After that, it will be sorted out with a central server and encrypted list of origins. Sounds good? > you absolutely want to authenticate the client (it might not always be the user's own browser) in addition to the user/grant Cool part is you still can. Provider can look at "client" the token was issued to, and reject if it does not match with some authorized Client record in the database. It's rather flexible for any scenario.