Re: [GNAP] Consensus Call on Continuation Request

[Fabien Imbault <[e-mail]>]

Ok, could you be more specific as to what you'd expect for the persistent
identifier ?
Thanks
Fabien

On Tue, Dec 15, 2020 at 1:50 PM Dave Tonge <[e-mail]> wrote:

> The persistent identifier is not a different issue, the current access
> token is used to reference an existing grant
> <https://github.com/ietf-wg-gnap/gnap-core-protocol/blob/main/draft-ietf-gnap-core-protocol.md#referencing-an-existing-grant-request-request-existing>
>
>
> It may not be more difficult for a client to *use* an access token at the
> AS / RS. But there is definitely an overhead on the client to *manage* this
> separate access token.
>
>
>
> On Tue, 15 Dec 2020 at 12:10, Fabien Imbault <[e-mail]>
> wrote:
>
>> I think we always said the access token was different, and handled as a
>> bound token.
>>
>> But it doesn't mean it's more difficult for the client that already needs
>> to be able to handle tokens anyway (bearer or not, both cases could occur).
>> It's mostly consolidating the logic.
>>
>> You're anticipating a lot of issues which have no specific reason to
>> occur, such as "can't be used with the token management APIs?". The
>> management API is part of the same general flow.
>> Anticipating issues with rotation is useful, but there are also many ways
>> it can be hard to manage through a stateful approach too. And
>> fundamentally, having everything in a common model (both for the internals
>> of the AS and for the API calls) will help improve by a large margin what
>> is probably the weakest point in today's infrastructure. But it's early to
>> be definitive as to the downstream impact either way.
>>
>> As for a persistent identifier instead of a continuation API, and
>> generally the end of your message, it's a totally unrelated issue to this
>> PR, so I suggest we don't discuss that here, but in a separate issue if
>> needed.
>>
>> Fabien
>>
>> On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge <[e-mail]>
>> wrote:
>>
>>> So we've established that this is a different access token, that
>>> requires different handling at the client. So keeping it could cause more
>>> confusion?
>>>
>>> As an RC, I will have to store the continue `uri` as although it could
>>> be static it could also be dynamic. Why do I need to store an access token
>>> as well. It brings me no benefit as an RC, in fact it brings more
>>> complexity. As I will now need to manage multiple types of tokens with
>>> different lifecycles:
>>>
>>> *Continuation token*
>>>   - can only be used at the continue endpoint (the name of which is
>>> confusing as I can use this endpoint to revoke a grant or get metadata on
>>> the grant).
>>>  - may be rotated each time it is used, or may not be
>>>  - provided in the `continue` section of the response
>>>  - must be sender-constrained
>>>  - can't be used with the token management APIs?
>>>  - can be used to identify the grant when making subsequent grants
>>>
>>> *Access token(s) to use at RS*
>>>   - can only be used at the specified RS
>>>   - may be sender constrained
>>>   - when used at the RS, will not result in rotation
>>>
>>> From my perspective, most use-cases will require the RC to have a
>>> persistent identifier for the grant. Why not bring this into the protocol
>>> and let the AS provide this persistent identifier (through the form of the
>>> continue uri). Using a rotating access token as a persistent identifier
>>> doesn't seem like the right choice.
>>>
>>> I see no security benefit to having the continuation access token. It
>>> doesn't matter if the continue uri leaks as it is useless without an
>>> accompanying signature, i.e. any security benefit of having an access token
>>> is already provided by having a signature.
>>>
>>> The only benefits that I can see are:
>>>  - If the AS wants to be fully stateless, then you can encode more data
>>> in a token than in a uri
>>>  - If the AS wants to have a static endpoint for CRUD operations on the
>>> grant
>>>  - To allow the AS to identity a previous grant
>>>
>>> If we dropped the access token for the continue endpoint and rather
>>> mandated a dynamic uri this would make things conceptually easier to
>>> understand, easier for the RC to implement, easier to debug and less chance
>>> of errors when rotating tokens (i.e. race conditions could be quite likely
>>> if the AS always rotates the token)
>>>
>>> *One-off grant with no continuation or ongoing management:*
>>> RC sends signature and metadata, no `continue` response provided,
>>> therefore no grant management possible
>>>
>>> *Grant with ongoing management*
>>> RC sends signature and metadata, AS responds with a continue uri that
>>> has these purposes:
>>>  - can be used by the RC to continue/update, read or revoke the grant
>>>  - can be used by the RC when making a new grant to identify the
>>> previous grant
>>>
>>> As an RC the only permanent items I need to store are:
>>>  - the continue uri associated with the grant
>>>  - any access tokens I receive for the grant
>>>
>>> Dave
>>>
>>> On Tue, 15 Dec 2020 at 10:11, Fabien Imbault <[e-mail]>
>>> wrote:
>>>
>>>> Hi Torsten,
>>>>
>>>> You're right on both accounts.
>>>> - for the first remark, it fits quite nicely the init request  /
>>>> continuation pattern
>>>> - for the second remark, it is a sort of handle for the
>>>> continuation request, which will eventually lead to the issuance or refresh
>>>> of standard access tokens
>>>>
>>>> Having a specific name is a possibility, I actually suggested that too
>>>> at some point.
>>>>
>>>> Fabien
>>>>
>>>> On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt <
>>>> [e-mail]> wrote:
>>>>
>>>>> Hi Fabien,
>>>>>
>>>>> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <
>>>>> [e-mail]>:
>>>>> >
>>>>> > Hi,
>>>>> >
>>>>> > On the contrary your feedback is most welcome.
>>>>> >
>>>>> > It doesn't accept any token, it needs the particular token as
>>>>> described in 3.1 and which is not a bearer token (that's what the "key" :
>>>>> true parameter is supposed to convey).
>>>>> >
>>>>> > Let us know if you need more clarifications.
>>>>>
>>>>> Thanks for the clarification. I think only accepting this kind of
>>>>> token at the continuation is a good idea otherwise the AS would need to be
>>>>> able to parse and understand all sorts of access tokens.
>>>>>
>>>>> Conceptually, I like the idea to treat the continuation as another
>>>>> kind of resource. However, here are some observations I want to share with
>>>>> you:
>>>>> - This resource is different as it will issue other access tokens (of
>>>>> this kind) to be used in subsequent continuation requests. This requires
>>>>> different handing on the client side.
>>>>> - This access token (if I understand correctly) is (or at least feels
>>>>> like) a handle for the underlying grant. So it is kind of the super access
>>>>> token to obtain other access tokens.
>>>>>
>>>>> I would consider using a different term to refer to this special
>>>>> access token, grant token or grant handle for example, in order to prevent
>>>>> confusion.
>>>>>
>>>>> best regards,
>>>>> Torsten.
>>>>>
>>>>>
>>>>> >
>>>>> > Best
>>>>> > Fabien
>>>>> >
>>>>> > Le sam. 12 déc. 2020 à 11:33, Torsten Lodderstedt <
>>>>> [e-mail]> a écrit :
>>>>> > Hi all,
>>>>> >
>>>>> > I didn’t follow GNAP closely so bear with me if me question seems
>>>>> naive.
>>>>> >
>>>>> > After having skimmed through the current draft and the PR, I‘m not
>>>>> sure whether the continuation requests accepts any access token issued to
>>>>> the RC or the particular access token returned in the „continue“ element in
>>>>> section 3.1..
>>>>> >
>>>>> > Can you please shed some light on this?
>>>>> >
>>>>> > kind regards,
>>>>> > Torsten.
>>>>> >
>>>>> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <
>>>>> [e-mail]>:
>>>>> >>
>>>>> >> 
>>>>> >> You're completely right. Allowing the dev to be lazy is a very good
>>>>> thing in general, because it's what we know will work :-)
>>>>> >>
>>>>> >> Le sam. 12 déc. 2020 à 03:15, Stephen Moore <[e-mail]> a
>>>>> écrit :
>>>>> >> Hi Fabien,
>>>>> >>
>>>>> >> For #3) Even after I typed out the hypothetical attack, that was
>>>>> sort of in the back of my mind, it isn't a huge risk there. So I actually
>>>>> agree with Dick there. Something doesn't sit right with me for the unique
>>>>> URL solution, so I don't like it and came up with a hypothetical that seems
>>>>> like it could be a down side.
>>>>> >>
>>>>> >> I still think the access token model with the signed request is the
>>>>> way I'd like to go, because again, it's a mechanism I'd be implementing
>>>>> anyway to talk to any 'normal' resource. The fact is there is _something_
>>>>> representing context that has to pass back and forth here, whether that is
>>>>> an access token (which I feel like is more flexible for extensions etc), a
>>>>> unique url, or even a cookie sent in the cookie header. So just to
>>>>> re-iterate, I'm a +1 on this pull request, speaking as a lazy developer ;)
>>>>> >> -steve
>>>>> >>
>>>>> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <
>>>>> [e-mail]> wrote:
>>>>> >> Again speaking in my own name here.
>>>>> >>
>>>>> >> Dick, we know you'd prefer to have a different design, but this PR
>>>>> shouldn't be about that.
>>>>> >>
>>>>> >> Back on your 3 items :
>>>>> >>
>>>>> >> 1) yes we could make pre-register mandatory, but we already decided
>>>>> that wouldn't be how that would work. We have a client instance that allows
>>>>> a more generic and flexible pattern (which BTW also allows what you want)
>>>>> >>
>>>>> >> 2) instead of blame arguments of who's less
>>>>> restful/HATEOAS/whatever that have the tenancy to flame conversations, I
>>>>> suggest we speak in less abstract terms and ask ourselves what that means
>>>>> in practice for devs. Stephen and several others (myself included) have
>>>>> expressed that it wouldn't be harder to implement, it would even simplify
>>>>> things quite a lot. If you disagree please send us a code sample to really
>>>>> show that point by example, because that's really not obvious.
>>>>> >>
>>>>> >> 3) "If someone has the client credentials, they can impersonate the
>>>>> client, and all bets are off." Are you seriously making this argument?
>>>>> Because if you have a better proposal than using cryptographic keys, I'm
>>>>> all hears. You make it look like there's a problem, while in reality we're
>>>>> only relying on the basic assumption of all modern digital communications.
>>>>> >>
>>>>> >> And more importantly you never responded to the issues of how to
>>>>> avoid the security pitfalls of what you proposed.
>>>>> >>
>>>>> >> Fabien
>>>>> >>
>>>>> >>
>>>>> >> Le sam. 12 déc. 2020 à 00:35, Dick Hardt <[e-mail]> a
>>>>> écrit :
>>>>> >>
>>>>> >>
>>>>> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <[e-mail]>
>>>>> wrote:
>>>>> >> But from the spec:
>>>>> >> "
>>>>> >> When sending a non-continuation request to the AS, the RC MUST
>>>>> identify itself by including the client field of the request...
>>>>> >> ...
>>>>> >> key (object / string) : The public key of the RC to be used in this
>>>>> request as described in {{request-key}}. This field is REQUIRED.
>>>>> >> ...
>>>>> >> "
>>>>> >> So on the initial request, the key will be there.
>>>>> >>
>>>>> >> The client field can be an object or a string. If the client is
>>>>> pre-registered, then a string could be provided instead of an object.
>>>>> >>
>>>>> >>
>>>>> >> If you don't have the access token, then how do you differentiate
>>>>> between two requests from the same web application by two different users?
>>>>> Is the web application supposed to have different credentials for every
>>>>> request?
>>>>> >>
>>>>> >> The AS returns a URI for manipulating the request. I would change
>>>>> the spec so that each request would have a unique URI. This is the usually
>>>>> RESTful pattern that the resource (the grant request) has an URI.
>>>>> >>
>>>>> >>
>>>>> >> So in this case, the easy way out is to pass the access token to
>>>>> the client, who then, as i stated before, treats the continue request as a
>>>>> RS call (albeit a specialized version of the RS where the RS is the AS) OR
>>>>> to use the unique URL,
>>>>> >> but that seems open to a brute force attack by a malicious RC.
>>>>> (What would be the point of that attack, I don't know, I guess if someone
>>>>> had the client credentials but not any subjects/resources they could try to
>>>>> intercept the grant via continue... I just don't feel right locking things
>>>>> down to unique URLs that way.)
>>>>> >>
>>>>> >> If someone has the client credentials, they can impersonate the
>>>>> client, and all bets are off.
>>>>> >>
>>>>> >> LOTS of RS servers return a resource specific URL -- my proposal is
>>>>> no different.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> -steve
>>>>> >>
>>>>> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <[e-mail]>
>>>>> wrote:
>>>>> >> Hi Stephen
>>>>> >>
>>>>> >> The client is signing the first request. The key *might* be in the
>>>>> body. The client is signing all the subsequent requests as well. The
>>>>> "access token" is not needed by the client to prove it is authorized as the
>>>>> client is proving it is the same client again.
>>>>> >>
>>>>> >> In other words, I don't see the need for an access token, so it
>>>>> does not need to be put in a URL or an auth header.
>>>>> >>
>>>>> >> If a developer really, really wants to hand context back to the
>>>>> client for subsequent calls, they can put it in the URL or some other
>>>>> method. Putting it in the HTTP Authorization header is confusing because it
>>>>> is NOT an access token -- it is the context of the request.
>>>>> >>
>>>>> >> ᐧ
>>>>> >>
>>>>> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <[e-mail]>
>>>>> wrote:
>>>>> >> Even though I've only been lightly following things, I feel the
>>>>> need to voice my preference as a developer since I will probably someday
>>>>> have to either write a RC or RS...
>>>>> >>
>>>>> >> The way I see it is the RC makes the initial request to the AS as
>>>>> part of this request, it provides it's key in the body... (So no use of the
>>>>> Authorization header)
>>>>> >> At this point that request, represented by the continue URL +
>>>>> "Access Token", from my lazy developer standpoint, is a Resource Endpoint
>>>>> and Access Token, and the AS is acting as a specialized RS in this case.
>>>>> >> So my client posts to whatever URL with the 'access token' in the
>>>>> authorization header, just like acting on any other resource I have a token
>>>>> for. YES, I get a new token value to use every call, and there is a
>>>>> decision point of "Do I have another continue, or do I have a real token
>>>>> for the resource..." But the mechanism is the same to me in the client.
>>>>> >> Personally I like that, because if I have an access_token, I
>>>>> already think "Put it in the auth header."
>>>>> >>
>>>>> >> So my vote would be +1 for the pull request at this time.
>>>>> >> -steve
>>>>> >>
>>>>> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <[e-mail]>
>>>>> wrote:
>>>>> >> inline ...
>>>>> >>
>>>>> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <[e-mail]>
>>>>> wrote:
>>>>> >> Others had already responded to this previous thread, but I wanted
>>>>> to add a couple points to clarify some things.
>>>>> >>
>>>>> >>> 3) What the client has to do with the "access token" is not the
>>>>> same as access tokens for an RS. The client gets a new "access token" for
>>>>> each grant request, and for each API call to the AS, and the client learns
>>>>> it can not make any more API calls for that specific request when it does
>>>>> not get an "access token" back. This is a completely different design
>>>>> pattern than calling an RS API with an access token, and is a new design
>>>>> pattern for calling APIs. This adds complexity to the client that it would
>>>>> not normally have, and I don't think GNAP is the right place to start a new
>>>>> design pattern.
>>>>> >>>
>>>>> >>
>>>>> >> I’m not sure what you mean by these being different — the whole
>>>>> point of the design is that the client would be doing the same thing with
>>>>> the access token at the AS that it does with the RS by re-using the access
>>>>> token structure. Can you please describe what the differences are, apart
>>>>> from the rotation? Presentation of the token and signing of the message are
>>>>> identical.
>>>>> >>
>>>>> >> The client is getting the "access token" from its API. It is not
>>>>> using an "access_token" in other API calls to the AS.
>>>>> >>
>>>>> >>
>>>>> >> Rotation of the access token and artifacts for ongoing continuation
>>>>> responses is a separate issue to be discussed:
>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87
>>>>> >>
>>>>> >> And for what it’s worth, GNAP is absolutely the right place to have
>>>>> new designs — not that this is one.
>>>>> >>
>>>>> >> You are proposing a new way for an API to provide context for
>>>>> subsequent API calls. Looks out of scope to me.
>>>>> >>
>>>>> >>
>>>>> >>> 4) Clients that only want claims from the AS and no access tokens
>>>>> will be required to support an API calling mechanism they would not have to
>>>>> support otherwise.
>>>>> >>
>>>>> >> Correct, but the delta between the calls a client would make with
>>>>> and without an access token is vanishingly small. The client has to sign
>>>>> the initial request in some fashion, and it will sign the continuation
>>>>> request in the same exact fashion, but now include an access token in that
>>>>> request.
>>>>> >>
>>>>> >> Per my other point, there is no value to me in my implementations
>>>>> of passing context back and forth between the client and AS -- so it is
>>>>> extra work providing no value.
>>>>> >>
>>>>> >> Also, any client authentication mechanism that wants to use the
>>>>> HTTP Authentication header is precluded from using it.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> Clients making a request to an AS and not getting an access token
>>>>> is a new design pattern. I think it has value and should be included, but
>>>>> OAuth today shows us the immense value of getting access tokens for calling
>>>>> APIs, and so we shouldn’t optimize away from that pattern.
>>>>> >>
>>>>> >>>
>>>>> >>> 5) If the AS does not provide an "access token", there is no
>>>>> mechanism for a client to delete the request, as the client is not allowed
>>>>> to make a call without an "access token".
>>>>> >>
>>>>> >> More properly, if the AS does not provide a “continue” field then
>>>>> the client can’t delete the request — and yes, that’s intentional. The AS
>>>>> is telling this client instance that it can’t do anything else with this
>>>>> ongoing request. If the AS wants to allow the client to manage it, it will
>>>>> include the mechanisms to do so in the “continue” field.
>>>>> >>
>>>>> >> There is nuance in that intention. A related concern is that
>>>>> deleting a request does not seem like it is a "continue" operation.
>>>>> >>
>>>>> >>
>>>>> >>>
>>>>> >>> 6) There is no standard identifier for the request. Debugging and
>>>>> auditing are hampered by the client and AS having no standard way to
>>>>> identifying a request. While one AS may provide a unique URL for each grant
>>>>> request, another AS may use a persistent "access token" to identify the
>>>>> grant request, and other ASs may issue a new "access token" on each API
>>>>> call, providing no persistent identifier for the request.
>>>>> >>
>>>>> >> Debugging and auditing this kind of thing are functions of the AS.
>>>>> How is interoperability harmed by different ASs having different methods to
>>>>> identify their internal data elements? The client doesn’t need any
>>>>> knowledge of the AS’s identifiers, it just needs to know the next steps for
>>>>> continuing the negotiation.
>>>>> >>
>>>>> >> Debugging between the client and the AS was what I was referring
>>>>> to. How does a client developer identify the request when communicating to
>>>>> the AS developer. Seems complicated.
>>>>> >>
>>>>> >> ᐧ
>>>>> >> --
>>>>> >> TXAuth mailing list
>>>>> >> [e-mail]
>>>>> >> https://www.ietf.org/mailman/listinfo/txauth
>>>>> >> ᐧ
>>>>> >> --
>>>>> >> TXAuth mailing list
>>>>> >> [e-mail]
>>>>> >> https://www.ietf.org/mailman/listinfo/txauth
>>>>> >> --
>>>>> >> TXAuth mailing list
>>>>> >> [e-mail]
>>>>> >>
>>>>> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1608345320000000&usg=AOvVaw0r39lH4qVOu0IQPJJYtSpI
>>>>>
>>>>> --
>>>> TXAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>
>>>
>>> --
>>> Dave Tonge
>>> CTO
>>> [image: Moneyhub Enterprise]
>>> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1
>>> 6FL
>>> t: [phone]
>>>
>>> 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 809360) at *https://register.fca.org.uk/
>>> <https://register.fca.org.uk/>*. Moneyhub Financial Technology is
>>> registered in England & Wales, company registration number  06909772 .
>>> Moneyhub Financial Technology Limited 2019 ©
>>>
>>> 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 Moneyhub Financial Technology Limited or of any other group
>>> company.
>>>
>>> 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 809360) at https://register.fca.org.uk/.
>>> Moneyhub Financial Technology is registered in England & Wales, company
>>> registration number 06909772. Moneyhub Financial Technology Limited 2020 ©
>>> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1
>>> 6EA.
>>>
>>> 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 Moneyhub Financial Technology Limited or of any other group
>>> company.
>>>
>>>
>
> --
> Dave Tonge
> CTO
> [image: Moneyhub Enterprise]
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
> t: [phone]
>
> 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 809360) at *https://register.fca.org.uk/
> <https://register.fca.org.uk/>*. Moneyhub Financial Technology is
> registered in England & Wales, company registration number  06909772 .
> Moneyhub Financial Technology Limited 2019 ©
>
> 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 Moneyhub Financial Technology Limited or of any other group
> company.
>
> 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 809360) at https://register.fca.org.uk/.
> Moneyhub Financial Technology is registered in England & Wales, company
> registration number 06909772. Moneyhub Financial Technology Limited 2020 ©
> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1
> 6EA.
>
> 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 Moneyhub Financial Technology Limited or of any other group
> company.
>
>