[Openid-specs-mobile-profile] Feedback on CIBA

Dave Tonge dave.tonge at momentumft.co.uk
Wed Jun 13 05:10:43 UTC 2018

Hi Mike

Its a good point with regards to pushing tokens and that mode is unlikely
to be supported by UK OpenBanking - they'll rely on the polling method.

>From a FAPI perspective we currently do include the notification mode, but
on reflection I think that it would be preferable to change the
notification mode to NOT deliver the token, but rather to inform the client
that they can go and fetch the token. i.e. the payload for client
notification could contain the auth_req_id, but nothing else. The client
would then need to make an authenticated call to the token endpoint to get
the token. This is how webhooks work in the banks that support them - no
sensitive data or token is sent via webhook, rather ids are sent which can
be used by an authenticated client to access resources.

John, Bjorn, Gonzalo what do you think about this approach? It would
simplify the document quite a bit and in my mind brings the best of both
worlds: no polling but secure token delivery.


On 7 June 2018 at 20:11, Mike Schwartz <mike at gluu.org> wrote:

> MODRNA Group,
> CIBA was discussed on the UMA WG call today. Eve has been working on a
> compare/contrast analysis between UMA and CIBA. And this discussion got me
> thinking a little more...
> One point from Justin Richer was that you are sending tokens back to the
> Client Notification Endpoint. This is risky, as you are trusting DNS. UMA
> makes the client authenticate at the token endpoint to obtain the tokens.
> Pushing tokens was discussed and dismissed as lacking security. I'm
> surprised the Open Banking group was ok with this.
> I also wonder if the response from the bc_authorize should include an
> id_token--I think it should be some other signed JWT assertion (with many
> of the claims present in an id_token). It seems weird to me to return an
> id_token to a client when the subject is not the person connected to the
> user agent.
> IMHO, CIBA could be accomplished using UMA as the security mechanism, with
> bc_authorize as the RS (protected endpoint on the OP). Its request and
> response would be defined much as you did.
> If you are starting from scratch, is it easier to implement CIBA with UMA
> for security, or CIBA plus it's one-off security model? Personally, I think
> UMA would be cheaper because we'd get more re-use.
> If I get some time in the next week, I'll try to write up a draft of CIBA
> using UMA. HEART also uses UMA, so it's not unheard of for an OpenID WG to
> use it as part of a solution.
> I know everyone wants to ship ASAP, so it's probably too late to bring
> this stuff up.
> - Mike
> _______________________________________________
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile

Dave Tonge
[image: Moneyhub Enterprise]
Moneyhub Financial Technology, 2nd Floor, Whitefriars Business Centre,
Lewins Mead, Bristol, BS1 2NT
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 561538) at fca.org.uk/register.
Moneyhub Financial
Technology is registered in England & Wales, company registration number
06909772 © . Moneyhub Financial Technology Limited 2018. DISCLAIMER: This
email (including any attachments) is subject to copyright, and the
information in it is confidential. Use of this email or of any information
in it other than by the addressee is unauthorised and unlawful. Whilst
reasonable efforts are made to ensure that any attachments are virus-free,
it is the recipient's sole responsibility to scan all attachments for
viruses. All calls and emails to and from this company may be monitored and
recorded for legitimate purposes relating to this company's business. Any
opinions expressed in this email (or in any attachments) are those of the
author and do not necessarily represent the opinions of Momentum Financial
Technology Limited or of any other group company.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20180613/1f614be9/attachment-0001.html>

More information about the Openid-specs-mobile-profile mailing list