[Openid-specs-mobile-profile] Feedback on CIBA
mike at gluu.org
Wed Jun 13 14:58:52 UTC 2018
But seriously, the UMA WG is discussing this right now. I think we'll
have a sequence diagram next week. My contention is that bc_authorize is
just an UMA protected API, requiring a scope (e.g. "openid_ciba").
It's ok if bc_authorize returns an id_token. And you'll still need to
describe the request and response in CIBA.
But we already have a permission ticket presented at the token
endpoint... and UMA describes in much richer detail, and with much more
community input, all the possibilities that may ensue other then
On 2018-06-13 09:09, Mike Schwartz wrote:
> 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
>> 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
>>> 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
>>> 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
>> Dave Tonge
>> 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
>> . 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.
>>  http://fca.org.uk/register
More information about the Openid-specs-mobile-profile