Re: [GNAP] Consensus Call on Continuation Request

[Aaron Parecki <[e-mail]>]

This has been a great discussion, and we've opened three new issues to
track things that came up in this thread that follow on from the changes in
the PR:

* persistent grant identifier
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/146
* rotation of tokens related to continuation request
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/147
* special label for access token used for continuation
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/149

The editors believe the specifics in this PR have rough consensus, so we're
going ahead with merging it.

Aaron


On Wed, Dec 16, 2020 at 3:37 AM Justin Richer <[e-mail]> wrote:

> On Dec 16, 2020, at 5:15 AM, Warren Parad <[e-mail]> wrote:
>
>
> #4 is a prereq for this discussion though. If the token is the identifier
> of the grant then it must be in the url to avoid the problem of arbitrary
> url construction. Of course the uri would be *https://as/grants/{grantIdentifier}
> <https://as/grants/%7BgrantIdentifier%7D>*. And this is actually
> independent of whether or not the token gets rotated.
>
>
> That’s not true: the identifier exposed to the client for some purpose
> like grant extension doesn’t have to be the same identifier that the AS
> uses for management. The latter is internal, and exposing internal state to
> the protocol shouldn’t be a requirement to the pattern.
>
>
> #3 The idea of a dynamic environment is important here, however the
> argument doesn't justify having this being the same endpoint. Nothing stops
> us from having two endpoints, one that requests an access token separate
> from the ones that manage the grant resource.
>
>
> Nobody said this has to be the same endpoint. In fact, this structure is
> being put in place to allow them to be separate endpoints. My original
> design in XYZ used a single endpoint and exposed an internal identifier of
> the ongoing grant request to the client within the protocol (the
> transaction handle). Changing this to a properly abstracted and protected
> API pattern allows much greater flexibility. The AS now has the choice of
> how it wants to manage its own dispatching, without the client needing to
> be aware of any of it since the client always does the same thing.
>
>  — Justin
>
>
> Warren Parad
> Founder, CTO
> Secure your user data and complete your authorization architecture.
> Implement Authress <https://bit.ly/37SSO1p>.
>
>
> On Wed, Dec 16, 2020 at 10:09 AM Dave Tonge <[e-mail]>
> wrote:
>
>> > Dave: which points changed your mind?
>>
>> 1. The issue with re-using client authentication across endpoints in the
>> OAuth 2 world
>> (token_endpoint_auth_methods_supported, revocation_endpoint_auth_methods_supported, introspection_endpoint_auth_methods_supported...)
>>
>> 2. The clear articulation of the 3 different functions of the AS
>> (including the idea of a self-hosted AS)
>>
>> 3. The aim to support a more dynamic environment where client
>> authentication only happens in the first interaction between the RC and the
>> AS
>>
>> 4. The agreement that there should be further discussion on whether this
>> access token should be rotated, and whether it should be an identifier of
>> the grant.
>>
>>
>> On Wed, 16 Dec 2020 at 00:02, Dick Hardt <[e-mail]> wrote:
>>
>>> Dave: which points changed your mind?
>>>
>>> On Tue, Dec 15, 2020 at 1:11 PM Dave Tonge <[e-mail]>
>>> 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 <[e-mail]> wrote:
>>>>
>>>>> On Dec 15, 2020, at 10:50 AM, Dave Tonge <[e-mail]>
>>>>> 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 <[e-mail]> 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 <[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
>>>>>>>> <https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g>
>>>>>>>> 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
>>>>>>>> <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: [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
>>>>>> <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
>>>>>> [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
>>>>> <https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g>
>>>>> 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
>>>>> <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: [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
>>>> <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
>> 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.
>>
>> --
>> TXAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>
>
> --
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>