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

Mike Schwartz mike at gluu.org
Wed Jun 13 14:09:28 UTC 2018


Congratulations... you're on the way to re-inventing UMA.

- Mike


On 2018-06-13 00:10, Dave Tonge wrote:
> 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.
> 
> Dave
> 
> 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
>> [1]
> 
> --
> 
> Dave Tonge
> CTO
>  [2]
> 
> Moneyhub Financial Technology, 2nd Floor, Whitefriars Business Centre,
> Lewins Mead, Bristol, BS1 2NTt: +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
> [3]. 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.
> 
> Links:
> ------
> [1] 
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
> [2]
> http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A
> [3] http://fca.org.uk/register


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