[Openid-specs-mobile-profile] CIBA Issues Review: Feedback for #62

Dave Tonge dave.tonge at momentumft.co.uk
Mon Mar 12 23:07:23 UTC 2018


Hi Nicolas

So the flow we have in UK OpenBanking is here (I've added more details
compared to my last email):

1. "payment" resource created at the RS using access token from
client_credentials grant (scoped to RP, but not user) - this resource has
all the details for the payment, e.g. payee, amount etc.
2. the RS returns the id of this new payment to the RP
3.this id is included in request object for redirect flow
4. the user is redirected to the OP (the bank) with the request object
5. the AS can then retrieve the payment details and have enough information
to gain authorisation from the user for the payment
6. after authentication and authorisation the user is redirected back to
the RP with an authorization code
7. the RP exchanges the code for an access token (and id_token)
8. the RP uses the access token to initiate the payment

More details are here:
https://openbanking.atlassian.net/wiki/spaces/DZ/pages/23363964

Dave


On 12 March 2018 at 16:27, <nicolas.aillery at orange.com> wrote:

> Hi Dave,
>
>
>
>    How do you plan to send the payment details to the AS?
>
>
>
> Nicolas
>
>
>
> *De :* Dave Tonge [mailto:dave.tonge at momentumft.co.uk]
> *Envoyé :* lundi 12 mars 2018 17:23
>
> *À :* AILLERY Nicolas IMT/OLS
> *Cc :* Petteri Stenius; PABLO GUIJARRO ENRIQUEZ;
> openid-specs-mobile-profile at lists.openid.net
> *Objet :* Re: [Openid-specs-mobile-profile] CIBA Issues Review: Feedback
> for #62
>
>
>
> HI Nicolas
>
>
>
> Thanks - that could work, but because banks will also support redirect
> based flows for payment, it would mean that the Payment RS had to support
> tokens with different permissions and take different auth related actions
> depending on the token received.
>
>
>
> The model I put in the email means that the RS is more "dumb" and the all
> authorisation decisions happen at the AS.
>
>
>
> The dependency between the 2 flows isn't required, but is one of the
> options. CIBA requires the RP to have access to some identifier for the
> user - we don't have the discovery mechanisms available that you have in
> the MNO space and we don't like the security considerations of using static
> identifiers such as a MSISDN or bank account number - this is why we quite
> like the idea of using an id_token that has been previously issued to the
> RP.
>
>
>
> Dave
>
>
>
> On 12 March 2018 at 16:11, <nicolas.aillery at orange.com> wrote:
>
> Hello Dave,
>
>
>
>    I’m not sure to understand the benefit to have the id_token in the
> second flow, as it create a dependency between the two flows.
>
>
>
>    Another option:
>
> -       The RP retrieves a refresh_token and access_token in a OAuth
> Authorization Code flow.
>
> -       When the RP needs to enforce a payment for this user,
>
> o    The RP gets a fresh access_token thanks to the refresh_token
>
> o    The RP uses the access_token on the Payment RS along with payment
> details (the access_token means “the user allowed me to request payments”)
>
> o    The Payment RS notifies the user of new payment request
>
> o    The user authenticates and authorizes the current payment
>
> o    Payment is done
>
>
>
> Regards,
>
> Nicolas
>
>
>
> *De :* Dave Tonge [mailto:dave.tonge at momentumft.co.uk]
> *Envoyé :* lundi 12 mars 2018 16:13
>
>
> *À :* AILLERY Nicolas IMT/OLS
> *Cc :* Petteri Stenius; PABLO GUIJARRO ENRIQUEZ;
> openid-specs-mobile-profile at lists.openid.net
> *Objet :* Re: [Openid-specs-mobile-profile] CIBA Issues Review: Feedback
> for #62
>
>
>
> The payment RS is protected by access tokens - but it should be agnostic
> to how those tokens are generated - whether by redirect or CIBA.
>
>
>
> Current steps are:
>
> 1. payment resource created using access token from client_credentials
> grant (scoped to RP, but not user)
>
> 2. id of the new payment resource included in request object for redirect
> flow - use redirected to OP (the bank)
>
> 3. user authenticates and authorises payment and is redirect back to RP
>
> 4. RP gets code and exchanges for access token and id_token
>
> 5. RP uses access token to initiate the payment
>
>
>
> In a subsequent CIBA flow it would be:
>
> 1. payment resource created using access token from client_credentials
> grant (scoped to RP, but not user)
>
> 2. id of the new payment resource and previously received id token
> included in request object for CIBA flow
>
> 3. OP (the bank) notifies user of new payment request, user authenticates
> and authorises payment
>
> 4. RP gets access token (by polling or notification)
>
> 5. RP uses access token to initiate the payment
>
>
>
> It would be good to get feedback on this.
>
>
>
> Thanks
>
>
>
> Dave
>
>
>
> On 12 March 2018 at 15:02, <nicolas.aillery at orange.com> wrote:
>
> Hello Dave,
>
>
>
>     For payment use cases, wouldn’t it be more interesting to use a
> Payment RS?
>
>     This RS would be protected by OAuth (via an access_token), would take
> the purchase as parameter and would include an out-of-band
> authentication/validation before processing the payment.
>
>
>
> Regards,
>
>
>
> Nicolas
>
>
>
> *De :* Dave Tonge [mailto:dave.tonge at momentumft.co.uk]
> *Envoyé :* lundi 12 mars 2018 15:05
>
>
> *À :* AILLERY Nicolas IMT/OLS
> *Cc :* Petteri Stenius; PABLO GUIJARRO ENRIQUEZ;
> openid-specs-mobile-profile at lists.openid.net
> *Objet :* Re: [Openid-specs-mobile-profile] CIBA Issues Review: Feedback
> for #62
>
>
>
> Yes, that is correct.
>
>
>
> Although it is not always "more" permissions. Sometimes it is different
> permissions, e.g. each CIBA flow may be for a different payment.
>
>
>
> Dave
>
>
>
> On 12 March 2018 at 14:01, <nicolas.aillery at orange.com> wrote:
>
> Hello David,
>
>
>
>    Here, the first id_token enables to trigger a subsequent authentication.
>
>    Is the goal of this subsequent authentication to retrieve an
> access_token with more privileges?
>
>
>
> Nicolas
>
>
>
> *De :* Dave Tonge [mailto:dave.tonge at momentumft.co.uk]
> *Envoyé :* lundi 12 mars 2018 14:54
> *À :* AILLERY Nicolas IMT/OLS
> *Cc :* Petteri Stenius; PABLO GUIJARRO ENRIQUEZ;
> openid-specs-mobile-profile at lists.openid.net
> *Objet :* Re: [Openid-specs-mobile-profile] CIBA Issues Review: Feedback
> for #62
>
>
>
> Hi
>
>
>
> I think there is a valid use case for this.
>
> Outside of the MNO space we are considering whether a redirect-flow is a
> prerequisite before a CIBA flow can be initiated.
>
> The redirect flow would result in the RP having an id token, they could
> then use that id token to initiate multiple subsequent CIBA flows.
>
>
>
> Dave
>
>
>
> On 12 March 2018 at 13:23, <nicolas.aillery at orange.com> wrote:
>
> Hello Petteri,
>
>
>
>    I don’t think it’s a good idea to offer an interface to the user so
> that he can enter a MSISDN of his choice and trigger a challenge on the
> device corresponding to the MSISDN. Adding an antispam code is an approach,
> that is a pre-authentication of the user based on a secret shared amongst
> the user, all his apps and his MNO. It implies trust in all apps.
>
>    If this pre-authentication is necessary for security, why don’t
> standardize we it, by saying that CIBA is a second factor authentication
> after a first factor that is a login/password (or MSISDN/user_code)
> authentication?
>
>
>
> Regards,
>
> Nicolas
>
>
>
> *De :* Petteri Stenius [mailto:Petteri.Stenius at ubisecure.com]
> *Envoyé :* lundi 12 mars 2018 13:52
>
>
> *À :* AILLERY Nicolas IMT/OLS
> *Cc :* openid-specs-mobile-profile at lists.openid.net; PABLO GUIJARRO
> ENRIQUEZ; GONZALO FERNANDEZ RODRIGUEZ
> *Objet :* RE: CIBA Issues Review: Feedback for #62
>
>
>
> Hi Nicholas
>
>
>
> That is correct, the code will become known to all applications using back
> channel flows where I have logged on.
>
> Do you think there is a risk of the applications collecting the code and
> using the code for sending unsolicited authentication requests? Is the
> situation any worse than it is without user code?
>
> What we want to do is prevent anybody who only needs to know my phone
> number from sending unsolicited authentication requests.
>
>
>
> About OTP: My authentication device could generate and display the OTP in
> the device’s user interface.
>
>
>
> Regards,
>
> Petteri
>
>
>
>
>
> *From:* nicolas.aillery at orange.com <nicolas.aillery at orange.com>
> *Sent:* maanantai 12. maaliskuuta 2018 14.28
> *To:* Petteri Stenius <Petteri.Stenius at ubisecure.com>
> *Cc:* openid-specs-mobile-profile at lists.openid.net; PABLO GUIJARRO
> ENRIQUEZ <pablo.guijarroenriquez at telefonica.com>; GONZALO FERNANDEZ
> RODRIGUEZ <gonzalo.fernandezrodriguez at telefonica.com>
> *Subject:* RE: CIBA Issues Review: Feedback for #62
>
>
>
> Hello Petteri,
>
>
>
>    In the case you describe, the secret is not secret anymore (shared
> amongst all apps).
>
>    How would you implement an OTP-like antispam code?
>
>
>
> Regards,
>
> Nicolas
>
>
>
> *De :* Petteri Stenius [mailto:Petteri.Stenius at ubisecure.com
> <Petteri.Stenius at ubisecure.com>]
> *Envoyé :* lundi 12 mars 2018 12:52
> *À :* AILLERY Nicolas IMT/OLS
> *Cc :* openid-specs-mobile-profile at lists.openid.net; PABLO GUIJARRO
> ENRIQUEZ; GONZALO FERNANDEZ RODRIGUEZ
> *Objet :* RE: CIBA Issues Review: Feedback for #62
>
>
>
> Hi Nicholas,
>
>
>
> I am not trying to reproduce an oauth 2 use case with user code.
>
>
>
> Let me clarify with an example
>
>
>
> Registration
>
>
>
> 1.      I register for Mobile PKI service at my mobile operator
>
> 2.      I register a spam prevention code by sending a PIN code by SMS to
> my mobile operator
>
>
>
> Logon
>
>
>
> 1.      To logon to an application with Mobile PKI, I enter my mobile
> phone number on a logon form
>
> 2.      The application attempts to send authentication request to my
> mobile phone but receives an error code indicating spam prevention code is
> required
>
> 3.      The application presents a form for entering the spam prevention
> code
>
> 4.      I enter the PIN I registered
>
> 5.      Application is allowed to send authentication request to my
> mobile phone
>
>
>
>
>
> Regards,
>
> Petteri
>
>
>
>
>
> *From:* nicolas.aillery at orange.com <nicolas.aillery at orange.com>
> *Sent:* maanantai 12. maaliskuuta 2018 12.53
> *To:* Petteri Stenius <Petteri.Stenius at ubisecure.com>; GONZALO FERNANDEZ
> RODRIGUEZ <gonzalo.fernandezrodriguez at telefonica.com>
> *Cc:* openid-specs-mobile-profile at lists.openid.net; PABLO GUIJARRO
> ENRIQUEZ <pablo.guijarroenriquez at telefonica.com>
> *Subject:* RE: CIBA Issues Review: Feedback for #62
>
>
>
> Hello Petteri,
>
>
>
>    If the « user_code » is a way to materialize the fact that the user
> allowed a SP to use CIBA, I think we are very close to an OAuth2.0 use
> case, the user_code being an access_token. This situation looks like a
> nonsense for me.
>
>    It seems important to have a clear view of the use cases where the
> user_code is involved to address them the best way,
>
>
>
> Regards,
>
>
>
> Nicolas
>
>
>
> *De :* Petteri Stenius [mailto:Petteri.Stenius at ubisecure.com
> <Petteri.Stenius at ubisecure.com>]
> *Envoyé :* lundi 12 mars 2018 10:48
> *À :* GONZALO FERNANDEZ RODRIGUEZ; AILLERY Nicolas IMT/OLS
> *Cc :* openid-specs-mobile-profile at lists.openid.net; PABLO GUIJARRO
> ENRIQUEZ
> *Objet :* RE: CIBA Issues Review: Feedback for #62
>
>
>
> Hello,
>
>
>
> I have written a proposal for this feature into issue tracker
> https://bitbucket.org/openid/mobile/issues/62/ciba-support-
> for-spam-prevention-code-in
>
>
>
> My proposal for name of parameter is user_code. The code is used to
> authorize sending an authentication request to user’s authentication
> device. In other words to prevent unsolicited authentication requests from
> appearing on user’s authentication device.
>
>
>
> I completely agree that there are many cases where this mechanism is not
> required. Still it is quite easy to identify cases where it may be
> necessary. That is why the parameter is optional.
>
>
>
> The details of how user codes works and are registered is not within the
> scope of this proposal. However it is perfectly possible to implement user
> codes as one time passwords. For example, to authorize an authentication
> request you’d enter a one time code that is shown on the authentication
> device.
>
>
>
> Petteri
>
>
>
> *From:* Openid-specs-mobile-profile <openid-specs-mobile-profile-
> bounces at lists.openid.net> *On Behalf Of *GONZALO FERNANDEZ RODRIGUEZ
> *Sent:* lauantai 10. maaliskuuta 2018 14.49
> *To:* nicolas.aillery at orange.com
> *Cc:* openid-specs-mobile-profile at lists.openid.net; PABLO GUIJARRO
> ENRIQUEZ <pablo.guijarroenriquez at telefonica.com>
> *Subject:* Re: [Openid-specs-mobile-profile] CIBA Issues Review: Feedback
> for #62
>
>
>
> Hi Nicolas,
>
>
>
> First of all, thank you for your feedback.
>
>
>
> I understand your view, I personally don't like to use an anti-spam code
> in CIBA, however it is only a proposal that try to fullfil the requirements
> of this opened issue, and if the WG don't agree we can decide not include
> the anti-spam code :).  However I have to say that in spite of the fact
> that I agree that a secret among more than 2 people is not a secret, what
> is proposed to be included in the CIBA spec in a way to carry-out the
> anti-spam code in the protocol and the way that it is shared is out of the
> scope of this spec.
>
>
>
> The OpenID providers can offer a secure way to share the anti-spam code
> with the Service Providers asking the user for consent (of course). I
> personally don't see the utility of it, I only can think about it as a way
> where a user could have potentially more control on what he wants to allow
> to Service Providers, that is, those who has the anti-spam code could
> interact with the user using the CIBA flow, otherwise they must use the
> Device flow.
>
>
>
> Honestly I don't think these use cases makes sense, we don't have these
> kind of use cases reported by Petteri and we really think that a Service
> Provider shouldn't have any interest in doing spam and others couldn't do
> it because CIBA authentication request uses an authenticated endpoint and
> only Service Providers can use it, but it was the only way I thought it
> could be supported by the protocol.
>
>
>
> P.D: agree that “spam-code” can be confusing ☺
>
>
>
> Best,
>
> Gonza.
>
>
>
> *From: *"nicolas.aillery at orange.com" <nicolas.aillery at orange.com>
> *Date: *Friday, 9 March 2018 at 10:30
> *To: *GONZALO FERNANDEZ RODRIGUEZ <gonzalo.fernandezrodriguez@
> telefonica.com>
> *Cc: *PABLO GUIJARRO ENRIQUEZ <pablo.guijarroenriquez at telefonica.com>, "
> openid-specs-mobile-profile at lists.openid.net" <
> openid-specs-mobile-profile at lists.openid.net>
> *Subject: *RE: CIBA Issues Review: Feedback for #62
>
>
>
> Hello Gonzalo,
>
>
>
>    Here are two remarks about your proposal :
>
> -       I think using the wording ‘spam-code’ to describe an *anti*spam
> code will introduce some confusion.
>
> -       I’m not sure it’s a good idea to expose the antispam code on
> CIBA. This code is similar to a user password, so it should be a secret
> between a user and his MNO. It was created to protect the user in a
> situation where anybody was able to enter any MSISDN on a public form (e.g.
> the GSMA discovery page before an OpenId Connect interaction). In CIBA,
> it’s the SP that will call CIBA, so using an antispam code implies that the
> secret is also shared amongst all SP (is this still a secret?). On another
> hand, is there still a spam risk in CIBA? Yes, if SP allow any user to
> enter any MSISDN, but in this situation the SP should use the classic
> OpenId Connect flow (because the user is already using the SP to be able to
> enter a MSISDN). No, if the SP uses CIBA as a second factor. My proposal is
> that CIBA does not implement antispam code, and that MNO does not check the
> antispam code when CIBA is used.
>
>
>
>    What is your point of view about this proposal?
>
>
>
> Best regards,
>
> Nicolas
>
>
>
> *De :* Openid-specs-mobile-profile [mailto:openid-specs-mobile-
> profile-bounces at lists.openid.net
> <openid-specs-mobile-profile-bounces at lists.openid.net>] *De la **part de*
> GONZALO FERNANDEZ RODRIGUEZ
> *Envoyé :* vendredi 2 mars 2018 14:40
> *À :* openid-specs-mobile-profile at lists.openid.net
> *Cc :* PABLO GUIJARRO ENRIQUEZ
> *Objet :* [Openid-specs-mobile-profile] CIBA Issues Review: Feedback for
> #62
>
>
>
> Hi all,
>
>
>
> I continue asking you for feedback about another CIBA issue, in that cases
> is the #62 https://bitbucket.org/openid/mobile/issues/62/ciba-support-
> for-spam-prevention-code-in
>
>
>
> The spam-code belongs to the end-user, so it should be configured by the
> end-user in the OpenID Provider.
>
> The CIBA flow doesn't have an interactive session with the end-user, but
> is the user who is contacted directly in his authentication device, what
> means that the end-user won't have the possibility to introduce the
> spam-code in his authentication, so, it only could be done by the Client.
>
>
>
> We think that it would be possible to add support for that in CIBA as
> follow:
>
>
>
> 1.            A new OPTIONAL field "spam-code" in the CIBA authentication
> request.
>
> 2.            An specific error in case of the end-user had the anti-spam
> activatedin the OIDC and the Service Provider didn't include it in the
> authentication request.
>
>
>
> It is worth it to highlight that this would be an optional feature
> implemented by the OIDC's and it should be "out of the scope" of CIBA to
> define how the end-user would share the spam-code with the Service Provider
> and how the end-user would configure the spam-code in the OIDC.
>
>
>
> I would like to know again your point of view on that in order to resolve
> this issue.
>
>
>
> Best,
>
> Gonza.
>
>
>
>
> ------------------------------
>
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
>
> ------------------------------
>
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
>
> _______________________________________________
> 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*
>
> CTO
>
> [image: Image supprimée par l'expéditeur. Moneyhub Enterprise]
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
>
> 10 Temple Back, Bristol, BS1 6FL
> <https://maps.google.com/?q=10+Temple+Back,+Bristol,+BS1+6FL&entry=gmail&source=g>
>
> *t: *+44 (0)117 280 5120
>
>
>
> Moneyhub Enterprise is a trading style of Momentum Financial Technology
> Limited which is authorised and regulated by the Financial Conduct
> Authority ("FCA"). Momentum Financial Technology is entered on the
> Financial Services Register (FRN *561538*) at fca.org.uk/register.
> Momentum Financial Technology is registered in England & Wales, company
> registration number *06909772* © . Momentum Financial Technology Limited
> 2016. 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.
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
>
>
>
>
> --
>
> *Dave Tonge*
>
> CTO
>
> [image: Image supprimée par l'expéditeur. Moneyhub Enterprise]
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
>
> 10 Temple Back, Bristol, BS1 6FL
> <https://maps.google.com/?q=10+Temple+Back,+Bristol,+BS1+6FL&entry=gmail&source=g>
>
> *t: *+44 (0)117 280 5120
>
>
>
> Moneyhub Enterprise is a trading style of Momentum Financial Technology
> Limited which is authorised and regulated by the Financial Conduct
> Authority ("FCA"). Momentum Financial Technology is entered on the
> Financial Services Register (FRN *561538*) at fca.org.uk/register.
> Momentum Financial Technology is registered in England & Wales, company
> registration number *06909772* © . Momentum Financial Technology Limited
> 2016. 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.
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
>
>
>
>
> --
>
> *Dave Tonge*
>
> CTO
>
> [image: Image supprimée par l'expéditeur. Moneyhub Enterprise]
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
>
> 10 Temple Back, Bristol, BS1 6FL
> <https://maps.google.com/?q=10+Temple+Back,+Bristol,+BS1+6FL&entry=gmail&source=g>
>
> *t: *+44 (0)117 280 5120
>
>
>
> Moneyhub Enterprise is a trading style of Momentum Financial Technology
> Limited which is authorised and regulated by the Financial Conduct
> Authority ("FCA"). Momentum Financial Technology is entered on the
> Financial Services Register (FRN *561538*) at fca.org.uk/register.
> Momentum Financial Technology is registered in England & Wales, company
> registration number *06909772* © . Momentum Financial Technology Limited
> 2016. 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.
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
>
>
>
>
> --
>
> *Dave Tonge*
>
> CTO
>
> [image: Image supprimée par l'expéditeur. Moneyhub Enterprise]
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
>
> 10 Temple Back, Bristol, BS1 6FL
> <https://maps.google.com/?q=10+Temple+Back,+Bristol,+BS1+6FL&entry=gmail&source=g>
>
> *t: *+44 (0)117 280 5120
>
>
>
> Moneyhub Enterprise is a trading style of Momentum Financial Technology
> Limited which is authorised and regulated by the Financial Conduct
> Authority ("FCA"). Momentum Financial Technology is entered on the
> Financial Services Register (FRN *561538*) at fca.org.uk/register.
> Momentum Financial Technology is registered in England & Wales, company
> registration number *06909772* © . Momentum Financial Technology Limited
> 2016. 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.
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>


-- 
Dave Tonge
CTO
[image: Moneyhub Enterprise]
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Momentum Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Momentum Financial Technology is entered on the
Financial Services Register (FRN 561538) at fca.org.uk/register. Momentum
Financial Technology is registered in England & Wales, company registration
number 06909772 © . Momentum Financial Technology Limited 2016. 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/20180312/87dcd615/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 463 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20180312/87dcd615/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 463 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20180312/87dcd615/attachment-0003.jpg>


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