Security Considerations, from OSW session about RAP and comparing with CIBA-PUSH

[michielbdejong]

Notes from OSW session about RAP are here:
https://hackmd.io/CDKQ5EfoT9OQBgLpFTLHdg

I was just looking up the security considerations of CIBA-PUSH, which basically apply to OCM as well:

https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.14

This specification defines a method of token delivery, "Push Callback", which differs from standard OAuth 2.0 flows. Most OAuth 2.0 and OpenID Connect profiles require the Client to authenticate at the token endpoint in order to retrieve access tokens, ID Tokens, and refresh tokens. However, with the CIBA Push mode, tokens are delivered directly to the Client at its Client Notification Endpoint. Implementers should ensure that appropriate security controls are in place for this endpoint and its registration with the OP. CIBA requires that a hash of the access token, a hash of the refresh token, and the auth_req_id itself are included in the ID Token when the Push mode is used. This allows the Client to verify that the values in the Push Callback have not been tampered with. Implementers using push tokens should also consider issuing sender-constrained access tokens to mitigate the risk of the tokens being intercepted.

[michielbdejong]

Also https://openid.net/specs/openid-financial-api-ciba.html

The push mode is not permitted by this specification as it delivers tokens to the client by calling an endpoint owned by the client. This substantially differs from the established pattern of retrieving tokens by presenting client authentication to the token endpoint, and it may have security concerns that are currently unknown.

So we basically need to have an additional redirect before the clients will need to authenticate (and possibly register) in the usual ways before they get their hands on a token

[michielbdejong]

This study culminated in #98 (comment)