Re: [GNAP] Consensus Call on Continuation Request
Dick Hardt <dick.hardt@gmail.com> Tue, 15 December 2020 23:02 UTC
Return-Path: <dick.hardt@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE8F3A0800 for <txauth@ietfa.amsl.com>; Tue, 15 Dec 2020 15:02:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTTdS1XOJzwM for <txauth@ietfa.amsl.com>; Tue, 15 Dec 2020 15:02:05 -0800 (PST)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57F6E3A07F5 for <txauth@ietf.org>; Tue, 15 Dec 2020 15:02:04 -0800 (PST)
Received: by mail-lf1-x134.google.com with SMTP id o19so18008536lfo.1 for <txauth@ietf.org>; Tue, 15 Dec 2020 15:02:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eKg902dKuaBc6lRE2sje5RiEgvJd8oGXeOa6ACO/wEY=; b=qwT7Yj2m5mq/u02TIqBgvasugYsUjWZli+HOTQTXxSenRpif9Q542Ak6/gMW56DL1S e+5zepy/NeMYnwcHWA2/q6FSP930pGhUlzIJLK0aUdZ8Fpk2Xp/JpT9Op2DYM630+a/h N2SVq/NDC92+4Cie4mcytOCnKfrrA6v8d8DoIWrJ/+jmWlQBXyLXsaU9NPjfK5mGPQX6 25FrcgFZGX1jLLrSrP3sRfv9/uD3fiIsgqqw8D65iVfLbv9I0FP6yhrXyoJ/7R3USotn gJVTp+1bGLt+0ECBlCC0j1YvTKihPd74kZwIlbD9GRcjJXEF/ifJ1ZFxKCKnrHAdQwbv yXXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eKg902dKuaBc6lRE2sje5RiEgvJd8oGXeOa6ACO/wEY=; b=QTbPYnG3iOal/nc1O8L6By7+6WBIUtVPWDhxR/aFyXPpxVwku9pOHMUe4kB7Xi/MTf JUS4wltKkGNt7LRHdEQVxOKhnBGyLQ/hxDtxOB40EZ0dU3l5IPM6vnEmhPkWGR3t2Seh jRap5umdvMnUenEZw7j9gDbjkYf1S0ROnEiU0dqiUmzZTNjBTWBjahvgc4TPLOIxXqkQ ZxOlAIluXNyeMKWKVPLoCq7a3y4y5xlCI3B+40jBpwSNwW1mdR6yITcY1UA/37GIIPw2 Z4NqjR7iOiFWnQ1tJ7MrksrKZg8ChRNxfI1sHrMy4jRK/2BD1QfYWSGGJqAqaA1awEy3 cT2g==
X-Gm-Message-State: AOAM53367Ji60uoQogOrWpJFYGxOFelE5ABlu19N0iayAeGyB9kifkvw u3ok3BSPB9k+PbFRt62K1mNdnzI+FhPQu81eUBQ=
X-Google-Smtp-Source: ABdhPJyrBgcCZIzfmqKECsv+ZzIAY3I3+/uYe2mPMhzXItQsSNrPcvGFsrjxFBOWQcYcX5F9c+OqJmLnhtppEBKnsUA=
X-Received: by 2002:a19:38e:: with SMTP id 136mr9119691lfd.346.1608073321865; Tue, 15 Dec 2020 15:02:01 -0800 (PST)
MIME-Version: 1.0
References: <CAM8feuSVX9dqfGXtmywBUz=wRkHRqaSOkvzmX0pvQuM6T=10nA@mail.gmail.com> <F6620639-2CE9-4A0A-A44C-6E973A5039BD@lodderstedt.net> <CAM8feuQg4wfUJ5c7=GDSqzPqbvmR3m+OkpqCDA=h4y8irbKojA@mail.gmail.com> <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> <CAM8feuRjvsz4GyQinsads689OP=v9CoXusT2mXBSiHWuM1Z3Aw@mail.gmail.com> <CAP-T6TR3EUO-9aaDpzW5_gQ5K6wnEuGOFdrZffaeciS4H9KAOA@mail.gmail.com> <CAM8feuRYQA=45zLVKEeAP=-9W+duaqWizfnxwfbKnJHiqdTxOg@mail.gmail.com> <CAP-T6TRd8qST9HMG=aLbB5QT31rP7WefV9XKD=ZS+SC5jKh2ew@mail.gmail.com> <4A8B9EDB-ABCF-4F14-B152-DEDD63A9F171@mit.edu> <CAP-T6TRFM14a86qy-skL3rpVZFHhK9yctG9o0Ji3mZq+ogdL=Q@mail.gmail.com> <86771CAF-A62A-4E12-99B5-D1D42BB95B11@mit.edu> <CAP-T6TSHhuju+GBgGaGgEgaBcckW4xxEFMFo_jfjjSzFFWaZjw@mail.gmail.com>
In-Reply-To: <CAP-T6TSHhuju+GBgGaGgEgaBcckW4xxEFMFo_jfjjSzFFWaZjw@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 15 Dec 2020 15:01:50 -0800
Message-ID: <CAD9ie-uHEErVw9Tv7sq4COXZmDZg5hO7kym846ahgz6kHAocYg@mail.gmail.com>
To: Dave Tonge <dave.tonge@moneyhub.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>, Justin Richer <jricher@mit.edu>, Steve Moore <srmoore@gmail.com>, Torsten Lodderstedt <torsten@lodderstedt.net>, txauth gnap <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001f66e005b688bf3e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/jPygeFQ9xPBxfR-u9VoYfzsiG10>
Subject: Re: [GNAP] Consensus Call on Continuation Request
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Dec 2020 23:02:13 -0000
Dave: which points changed your mind? On Tue, Dec 15, 2020 at 1:11 PM Dave Tonge <dave.tonge@moneyhub.com> wrote: > Thanks for the detailed response. > > I think you make the points well and I'm now in favour of the PR. > However I do think that to keep the consistency that keeps being > discussed, that the tokens shouldn't be rotated. > > I also think it would be good to have a discussion about "grant > management" and identifiers for a grant. > > Dave > > On Tue, 15 Dec 2020 at 17:30, Justin Richer <jricher@mit.edu> wrote: > >> On Dec 15, 2020, at 10:50 AM, Dave Tonge <dave.tonge@moneyhub.com> wrote: >> >> >> > The access token pattern has a lot of benefits, otherwise we wouldn’t >> have an entire OAuth ecosystem based on it >> >> *But what are the benefits in this particular use case?* The >> continuation API is not like any other API - it is integral to the AS. >> There are quite a few extensions to OAuth that use client authentication >> rather than access tokens. >> >> >> Yes, and the propagation of that has lead to a mess in the OAuth world. >> You’ve got re-definitions of client authentications at all different >> endpoints, they’re technically allowed to vary between endpoints (though I >> don’t know of it happening in practice, that feels like a downgrade attack >> waiting to happen to someone). Then there’s the fact that all the newest >> security mechanisms we have — PKCE, DPoP, and MTLS — don’t rely on client >> authentication at all to achieve security. All of these work without the >> client having credentials previously known to the AS, and we already know >> that GNAP is going to need to live in this more dynamic world. We need to >> think beyond what OAuth 2 has done in the past, and especially from our >> perceptions and assumptions of the models that drive OAuth 2’s decisions, >> lest we repeat its mistakes. >> >> Also, I want to challenge this idea of “integral to the AS” as a point. >> In OAuth 1, the API was “integral” to the server side, but in OAuth 2 we >> split that into the RS concept. Even though in practice, a lot of RS’s are >> still integrated to the AS in some fashion because it’s a single service, >> OAuth 2 is clear about what’s expected to be known by each component. For >> the AS as currently defined in GNAP, I’m seeing three distinct functions. >> As per the Terminology discussion, we don’t have explicit names for these >> yet: >> >> - starting a request; this is an endpoint to kick things off; it needs >> to be able to look up the rights asked for by the client (if it knows the >> client at all ahead of time) and make initial decisions about needed >> interaction and follow up >> - continuing a request; this is an API that needs to know the context of >> the request itself, including which key it’s bound to; this is separate >> from any identity of the client and possibly the user, but an AS >> implementation that has access to those elements can use them >> - interacting with the user; this is front-facing and in OAuth today is >> already deployed as a separate service in some places, we should embrace >> that at the very least (but doing so formally is a separate issue) >> >> Why separate these in this way? There is immense power in having a single >> consistent way to start the process. The “continuation API” gives us an >> HTTP-defined mechanism for managing a request over time, including the >> simple case of returning information from the front channel, but people >> have already raised the question of non-HTTP and self-hosted AS’s, which >> would probably want a different kind of continuation API to communicate to >> the AS. The same thing with separating out the interaction: there are going >> to be a lot of different ways to handle interaction out there, and not all >> of them will be “integral” to the AS in the way that a simple >> implementation might do. We’re defining a protocol based strongly on HTTP >> and JSON, but we should structure it in such a way that it can be extended >> and translated elsewhere in a clear way. >> >> This all raises the question: if we can rely on a unique URL for >> redirect-based interaction, why not here? The simple reason is that a URL >> is the :only: mechanism we have in the front channel for passing >> information, and we need to warn implementors against including sensitive >> information in it, and we need to protect it with additional items. We have >> access to more than just URLs when we’re dealing with the continuation API, >> and we ought to make use of all of our tools in ways that are consistent >> and make sense. >> >> From a previous email the advantages I see are: >> - more data can be encoded in a token than in a uri (this seems more of >> an edge case) >> - it can be an identifier for the grant (I don't agree with this) >> >> >> It allows the parts above to live separately, even if they don’t HAVE to. >> And it simplifies what we’re asking the client to do by making it >> consistent with other parts of the ecosystem. The AS offering an API >> doesn’t :have: to be different, and OpenID Connect showed us, with the >> UserInfo Endpoint, that that’s very much the case in practice. >> >> Having my client code do very similar things in slightly different ways >> is not simpler. >> >> >> Another question I have: *do we envisage granting access tokens to the >> RC that will allow it to manage multiple grants*? >> >> >> I don’t see that happening, personally, and it hasn’t been brought up as >> a use case to date. >> >> >> I also think there will be confusion with the signing being used for >> different things. Maybe it just needs to be called out in the spec that: >> >> Request 1: signature = client authentication >> Request 2+: signature = proof of possession for access token >> >> >> That’s more or less the intent of what’s in the specification right now, >> and why all the signature methods, which are used for both client auth and >> token possession, are all together in section 8 and not separated by use. >> (With the caveat: it’s only client authentication in the first request if >> the AS knows about the client instance ahead of time, which isn’t always >> going to be true.) That all can likely be made clearer, as is always the >> case with spec text. But you can use the signature methods with and without >> access tokens, and it only gets used without in an initial call where you >> don’t :have: an access token to present. >> >> Separating the different kinds of “client authentication" out in OAuth is >> the source of some real confusion. Like right now, what happens if you try >> to combine a client assertion, signed request objects for PAR, and DPoP >> proofs, all in a single request? All of these are optional and all of them >> “do client authentication” in some arguable fashion. I’ve worked on several >> systems and implemented these things, and their interplay is really >> confusing to manage and can go sideways really fast. And that’s just the >> work for a single endpoint, this gets repeated for introspection, >> revocation, CIBA, device, and on. >> >> At the end of the day I’m in favor of giving the client developers a very >> clear set of directions on what they need to do and how they need to access >> things, and treating the continuation as a token-bound API is, to me, the >> clearest pattern we can offer for this piece. >> >> — Justin >> >> >> >> >> >> >> >> >> >> On Tue, 15 Dec 2020 at 15:33, Justin Richer <jricher@mit.edu> wrote: >> >>> I agree with Fabien that the persistent identifier is a separate issue. >>> The current spec re-uses the access token for this artifact, but that’s >>> potentially brittle and could be changed out for something else. There’s an >>> issue asking for expanding on the use cases for this functionality (which >>> hasn’t been addressed by this PR): >>> >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>> >>> A potentially-rotating URI would be just as brittle, and so having a >>> single codified identifier for this artifact would be useful, but it does >>> assume some things about the nature of the AS. Every other use the client >>> has to manage the ongoing request over time doesn’t need an explicit >>> identifier. Just like with OAuth-protected APIs, the server can determine >>> the context not just from the URI but from the rest of the request, >>> including the access token itself. This is both more common and more >>> powerful than a strict reading of REST designs. It also follows the HATEOS >>> principles as the entire HTTP request is taken into account, including the >>> access token and signature portions. >>> >>> I’ll also point out that the rotation of these credentials is also filed >>> as a separate issue that’s not being addressed right now, so we can revisit >>> that discussion separately: >>> >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>> >>> As for the name, we could give it a different label. We have this same >>> pattern of issuing a resource-specific access token alongside a URL in the >>> Dynamic Registration specification, both in OAuth ( >>> https://tools.ietf.org/html/rfc7592#section-3) and OpenID Connect ( >>> https://openid.net/specs/openid-connect-registration-1_0.html#RegistrationResponse). >>> Here it’s called the “registration access token” — but what’s important >>> there, as it is here, is that it’s not a different kind of artifact that >>> the client now has to figure out how to use, it’s an access token plain and >>> simple. In the OAuth world this is a bearer token, since that’s what OAuth >>> 2 uses. In the GNAP world it’ll be a bound token, as that’s what we’re >>> looking to build on. This is also related to another future discussion >>> about responses tying an access token to a specific API that’s told to the >>> client, as we could potentially re-use those components and concepts here >>> as well: >>> >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/69 >>> >>> And finally, no speculation on the complexity is needed: I implemented >>> this pattern several months ago during the design team discussions when we >>> were considering this pattern, and the code is all online for people to >>> see. >>> >>> https://github.com/bspk/oauth.xyz-java/ >>> >>> On the AS side, the most interesting code to this discussion is in the >>> TransactionEndpoint class: >>> >>> >>> https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/java/io/bspk/oauth/xyz/authserver/endpoint/TransactionEndpoint.java >>> >>> Here, you’ll see that on initial request, the server looks up the client >>> to see if it’s been registered, but after that, it makes sure that the >>> token and key are appropriate for the ongoing request. From the client side >>> it’s even simpler. The client’s got a small service function to manage the >>> different signature methods that are implemented, and all of them can take >>> in an optional access token: >>> >>> >>> https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/java/io/bspk/oauth/xyz/http/SigningRestTemplateService.java >>> >>> The heavy lift is doing the actual signing, and you need that in order >>> to start the process anyway. Managing the access token as an artifact to >>> use at the API is completely trivial since the client already needs to >>> manage its own state internally to do any of this. And note that all of >>> this is changed from how it was before: Previously, the XYZ Protocol had >>> used a “transaction handle” returned by the AS that the client would use to >>> continue the request. However, this simple model was limiting, and the >>> design team adopted XAuth’s model of continuation being an API. In doing >>> so, we made it like all of the other APIs the client is going to call: in >>> the initial state, it doesn’t have any kind of access rights, it’s just >>> calling. From that initial call forward, the AS just needs to know that the >>> token and key match what it expects. >>> >>> In summary, my views are: >>> - The access token pattern has a lot of benefits, otherwise we wouldn’t >>> have an entire OAuth ecosystem based on it >>> - Magic URIs have a lot of drawbacks which are well understood; while >>> they can be mitigated, they can also be avoided >>> - Continuation is an API, and treating it like the other kinds of API >>> the client would call makes sense >>> - Calling this by a special name, like “grant access token” or >>> “continuation access token” is fine, but it should function like any other >>> access token >>> - The heavy lift for clients is on protecting the message >>> cryptographically, which they need to do anyway >>> >>> — Justin >>> >>> >>> On Dec 15, 2020, at 7:50 AM, Dave Tonge <dave.tonge@moneyhub.com> 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 <fabien.imbault@gmail.com> >>> 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 <dave.tonge@moneyhub.com> >>>> 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 <fabien.imbault@gmail.com> >>>>> 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 < >>>>>> torsten@lodderstedt.net> wrote: >>>>>> >>>>>>> Hi Fabien, >>>>>>> >>>>>>> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault < >>>>>>> fabien.imbault@gmail.com>: >>>>>>> > >>>>>>> > 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 < >>>>>>> torsten@lodderstedt.net> 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 < >>>>>>> fabien.imbault@gmail.com>: >>>>>>> >> >>>>>>> >> >>>>>>> >> 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 <srmoore@gmail.com> >>>>>>> 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 < >>>>>>> fabien.imbault@gmail.com> 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 <dick.hardt@gmail.com> >>>>>>> a écrit : >>>>>>> >> >>>>>>> >> >>>>>>> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> >>>>>>> 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 <dick.hardt@gmail.com> >>>>>>> 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 <srmoore@gmail.com> >>>>>>> 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 <dick.hardt@gmail.com> >>>>>>> wrote: >>>>>>> >> inline ... >>>>>>> >> >>>>>>> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> >>>>>>> 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 >>>>>>> >> TXAuth@ietf.org >>>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >> ᐧ >>>>>>> >> -- >>>>>>> >> TXAuth mailing list >>>>>>> >> TXAuth@ietf.org >>>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >> -- >>>>>>> >> TXAuth mailing list >>>>>>> >> TXAuth@ietf.org >>>>>>> >> >>>>>>> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1608345320000000&usg=AOvVaw0r39lH4qVOu0IQPJJYtSpI >>>>>>> >>>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> 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 >>>>> <https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g> >>>>> 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 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 >>>>> <https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g> >>>>> . >>>>> >>>>> 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 >>> <https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g> >>> 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 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 >>> <https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g> >>> . >>> >>> 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. >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> 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 >> <https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g> >> 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 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 >> <https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g> >> . >> >> 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 > <https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g> > 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 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 > <https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g> > . > > 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. > >
- [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Dick Hardt
- Re: [GNAP] Consensus Call on Continuation Request Warren Parad
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Dick Hardt
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Denis
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Dick Hardt
- Re: [GNAP] Consensus Call on Continuation Request Stephen Moore
- Re: [GNAP] Consensus Call on Continuation Request Dick Hardt
- Re: [GNAP] Consensus Call on Continuation Request Stephen Moore
- Re: [GNAP] Consensus Call on Continuation Request Dick Hardt
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Stephen Moore
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Torsten Lodderstedt
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Dick Hardt
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Dick Hardt
- Re: [GNAP] Consensus Call on Continuation Request Aaron Parecki
- Re: [GNAP] Consensus Call on Continuation Request Warren Parad
- Re: [GNAP] Consensus Call on Continuation Request Dick Hardt
- Re: [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Warren Parad
- Re: [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Dave Tonge
- Re: [GNAP] Consensus Call on Continuation Request Warren Parad
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Torsten Lodderstedt
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Dave Tonge
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Dave Tonge
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Warren Parad
- Re: [GNAP] Consensus Call on Continuation Request Dave Tonge
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Dave Tonge
- Re: [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Dave Tonge
- Re: [GNAP] Consensus Call on Continuation Request Dick Hardt
- Re: [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Dave Tonge
- Re: [GNAP] Consensus Call on Continuation Request Warren Parad
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Aaron Parecki
- Re: [GNAP] Consensus Call on Continuation Request Mike Varley