3 ms·

Since this offering appears to be heavily based on OAuth 2.0, if not completely compliant with it, how have you addressed the concerns set forth in RFC-6819 "OA

Since this offering appears to be heavily based on OAuth 2.0, if not completely compliant with it, how have you addressed the concerns set forth in RFC-6819 "OAuth 2.0 Threat Model and Security Considerations"[1]? And what reparations are SimpleFIN agreeing to provide in the event of customer information being compromised? 1 - http://tools.ietf.org/html/rfc6819 http://tools.ietf.org/html/rfc6819

iffycan 11y ago
It actually isn't based on OAuth2. For instance, consumers of the read only SimpleFIN protocol don't have to establish a relationship with the server -- they need only provide credentials. Also, the SimpleFIN Server does not redirect a client back to another server -- it is left to the user to deliver the credentials to the party(ies) of their choosing. As far as reparations, we haven't yet published that policy, but we will.
- AdieuToLogic 11y ago
  > It actually isn't based on OAuth2. Well, your spec requires use of the HTTP Bearer token[1], which is described in the Introduction section of RFC 6750 as being: "This specification defines the use of bearer tokens over HTTP/1.1 [RFC2616] using Transport Layer Security (TLS) [RFC5246] to access protected resources." So I hope you can understand my impression. And there are legitimate criticisms of using Bearer tokens[1]. With the offering you are considering, these are very significant. FWIW, you may think I'm being adversarial/hyper-critical/a-dick (or any combination therein). I can definitively say that in my mind I am not (in this particular case) _and_ that the questions/statements I've posted on this forum are "kindergarten level with mittens on" compared to what the eCommerce banking community will hit you with. If, as you said in a separate reply, you have worked in the PCI space for the last decade, then the scrutiny you will be exposed to will not be a surprise. 1 - http://hueniverse.com/2010/09/29/oauth-bearer-tokens-are-a-terrible-idea/ http://hueniverse.com/2010/09/29/oauth-bearer-tokens-are-a-t...

iffycan 11y ago

It actually isn't based on OAuth2. For instance, consumers of the read only SimpleFIN protocol don't have to establish a relationship with the server -- they need only provide credentials. Also, the SimpleFIN Server does not redirect a client back to another server -- it is left to the user to deliver the credentials to the party(ies) of their choosing. As far as reparations, we haven't yet published that policy, but we will.

AdieuToLogic 11y ago
> It actually isn't based on OAuth2. Well, your spec requires use of the HTTP Bearer token[1], which is described in the Introduction section of RFC 6750 as being: "This specification defines the use of bearer tokens over HTTP/1.1 [RFC2616] using Transport Layer Security (TLS) [RFC5246] to access protected resources." So I hope you can understand my impression. And there are legitimate criticisms of using Bearer tokens[1]. With the offering you are considering, these are very significant. FWIW, you may think I'm being adversarial/hyper-critical/a-dick (or any combination therein). I can definitively say that in my mind I am not (in this particular case) _and_ that the questions/statements I've posted on this forum are "kindergarten level with mittens on" compared to what the eCommerce banking community will hit you with. If, as you said in a separate reply, you have worked in the PCI space for the last decade, then the scrutiny you will be exposed to will not be a surprise. 1 - http://hueniverse.com/2010/09/29/oauth-bearer-tokens-are-a-terrible-idea/ http://hueniverse.com/2010/09/29/oauth-bearer-tokens-are-a-t...