From nobody Mon Oct 12 02:15:25 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3575A3A139F for ; Mon, 12 Oct 2020 02:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net 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 9I2fHxQPYKmm for ; Mon, 12 Oct 2020 02:15:21 -0700 (PDT) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 655E73A13A1 for ; Mon, 12 Oct 2020 02:15:21 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id e22so22220337ejr.4 for ; Mon, 12 Oct 2020 02:15:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=B+zu8Z6IFjR6XvnClH+JN2G0wxIU10R1/8gzOZNTusU=; b=KHhxaa2jd0OWE0BgNNmtN9YgmVi8pl4h2cIvCPtHBQYoh0AppDG/ZhghyLbJZDT4KK nRloJthzndtNnME/0twNQsjb41AFFeVlWOzDG8H4YZTRkrBoBWc4NwVSl1eN78YtmXgs yOX91GiGk7vSFExVflEnVHmnUs6HcAmpXkWUeFEQVv2Kfj5l8adl8dpsj13Ms4m5p5uL F0885LZcpAm0p+CYvnAex0DB0U3poXgRfYBRQY5peWT/l9SW7gPVwBF8PIkJV2fCR76h C5HmBusXwvj7qZ52QuSh+77HtyKVCFyZMEvUGSr+WuI4mgFHna4IqLkxcVWUtCf3qmgd b6Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=B+zu8Z6IFjR6XvnClH+JN2G0wxIU10R1/8gzOZNTusU=; b=Lp1OJ1dpSSMAtN4Kmz4KdEnocuwjGu06Am26IQRy7tOVKT+5XVdiRvQrqq+MVLPryO HvOPY4bfA2ba8gm+DP+hhHy1EPkrDsdLZdG7PsZndhwh5gkLZiSakpgEe90/YRIrZKlD fWlXokNRU1LqroFPp3oQNuLlJVGcrNPLXJbs7ew0X+Xzt5zJJOxnlUe1WmW3RP9QHUY0 oxGrOTlDmPTu2WbdI2DTjk4cv/UgvQWL+VbLEj5Hp83B5cgTQpUO0MbFck3MTmMcIQ3w 3rvX2zH7mMU3zhHQtJ2u5v4XS1Mu03n8ORKORsxNIcpjfzW4qUDNKhh709kp1qTcTXmB GMhA== X-Gm-Message-State: AOAM533PvaHT7sr5OK3OF32Wy42XwkH/7Kj/pvxplrMiQlbjR0DBPEsG x5CdiItLgTontJycKcsZw3lV/w== X-Google-Smtp-Source: ABdhPJz3W+XL4F4935cs0VQZERSmMSTgflSZp8RyDGxWNLxNNHazNefaLrCEu546xgWC8KCX832nvQ== X-Received: by 2002:a17:906:9702:: with SMTP id k2mr4556348ejx.494.1602494117707; Mon, 12 Oct 2020 02:15:17 -0700 (PDT) Received: from ?IPv6:2003:eb:8f1e:2acb:f17f:cd59:cd54:7b42? (p200300eb8f1e2acbf17fcd59cd547b42.dip0.t-ipconnect.de. [2003:eb:8f1e:2acb:f17f:cd59:cd54:7b42]) by smtp.gmail.com with ESMTPSA id a12sm10100615edy.87.2020.10.12.02.15.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2020 02:15:16 -0700 (PDT) Content-Type: multipart/signed; boundary=Apple-Mail-B60855C8-B52A-4F7F-B465-5268C6AD998A; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Mon, 12 Oct 2020 11:15:15 +0200 Message-Id: <81E51F61-E093-4467-BBDB-5FC1CF593598@lodderstedt.net> References: Cc: Neil Madden , Jeff Craig , vittorio.bertocci=40auth0.com@dmarc.ietf.org, OAuth WG In-Reply-To: To: Dave Tonge X-Mailer: iPad Mail (18A393) Archived-At: Subject: Re: [OAUTH-WG] Implementation questions around refresh token rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 09:15:24 -0000 --Apple-Mail-B60855C8-B52A-4F7F-B465-5268C6AD998A Content-Type: multipart/alternative; boundary=Apple-Mail-10B5E0BA-ADDD-444E-91D3-C837096880C6 Content-Transfer-Encoding: 7bit --Apple-Mail-10B5E0BA-ADDD-444E-91D3-C837096880C6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 12.10.2020 um 09:04 schrieb Dave Tonge : >=20 > =EF=BB=BF > Hi Neil >=20 > > refresh token rotation is better thought of as providing protection aga= inst insecure token storage on the client >=20 > I agree with your reasoning - and that was more the intent of what I said.= We've seen refresh token rotation used for confidential clients that have s= ecure storage (i.e. are run in a data center not on a mobile device) and it h= as caused problems with zero additional security benefits.=20 Those are good examples of why refresh token rotation should not be used if t= here are better ways available to protect refresh tokens from replay. Client= authentication or sender constrained refresh tokens are the better choice. >=20 > Dave >=20 >=20 >> On Mon, 12 Oct 2020 at 08:57, Neil Madden wro= te: >> I=E2=80=99m not sure I agree with this advice. Singling out private_key_j= wt and tls_client_auth suggests that the problem is an attacker being able t= o eavesdrop on the refresh request itself and then replay it. But if they ar= e able to do that then they can instead just steal the access tokens from th= e response. >>=20 >> I think refresh token rotation is better thought of as providing protecti= on against insecure token storage on the client (e.g. in browser localStorag= e). Both public and confidential clients are capable of creating secure conn= ections with TLS, but we assume that confidential clients (regardless of aut= h mechanism) have access to secure storage - otherwise they shouldn=E2=80=99= t be confidential clients in the first place. >>=20 >> I think the same reasoning applies here too - if a client has insecure st= orage then an attacker could just steal the access tokens instead. But I thi= nk the difference is that an attacker is more likely to gain temporary acces= s to local storage (e.g. when the user goes to the bathroom and leaves their= device unlocked) than they are to gain temporary access to eavesdrop on a c= onnection. The kind of vulnerabilities that allow eavesdropping tend to be r= epeatable so the attacker doesn=E2=80=99t need to steal a refresh token to e= nsure ongoing access, they can just steal the access tokens every time the c= lient refreshes. >>=20 >> That said, there are lots of vulnerabilities that would give an attacker r= epeatable access to the client=E2=80=99s local storage - e.g. XSS - so refre= sh token rotation only catches a subset of possible attacks. >>=20 >> =E2=80=94 Neil >>=20 >>> On 12 Oct 2020, at 05:43, Dave Tonge wrote= : >>>=20 >>> > Our goal is to prevent cases where we lose the ability to Refresh a To= ken due to transient issues (which have run the gamut from network problems t= o bad software updates on the AS side). >>>=20 >>> We've seen this issue quite a bit and it's very frustrating. I would sug= gest that refresh token rotation is not used for confidential clients that a= uthenticate with private_key_jwt or tls_client_auth.=20 >>>=20 >>>> On Wed, 7 Oct 2020 at 00:57, Jeff Craig wrote: >>>> My experience is more from the Client side of the equation on this prob= lem, but I do have some thoughts. Our goal is to prevent cases where we lose= the ability to Refresh a Token due to transient issues (which have run the g= amut from network problems to bad software updates on the AS side). Our use c= ase also does all token handling server-side, so our threat model is not the= same as the mobile application you described. There is a clear tradeoff in r= educing user friction with additional authorization events, and securing acc= ess. >>>>=20 >>>> The recommendation my team typically gives people building Authorizatio= n Servers with Refresh Token Rotation is to keep the old refresh token until= they see the new one (which means that there are generally two refresh toke= ns valid at any point in time, an unfortunate trade-off). A more difficult, b= ut potentially plausible implementation would be to hold onto the older Refr= esh Token until the newly issued Access Token is used (thus implying the ref= resh was successful on both sides). >>>>=20 >>>> We aren't trying to protect against multiple in-flight refreshes though= (we've done a LOT of work to attempt to remove that possibility in a global= ly consistent manner), we're trying to protect against a network interruptio= n that prevents the first use of R1, so our assumption is that R2.1 was comp= letely lost, and only R2.2 matters moving forward. Meaning: R1 is sent, A/R2= .1 is dropped in flight, R1 is sent again, A/R2.2 is returned and stored. Si= nce R1 was seen a second time, we recommend that R2.1 be ignored in future. N= ext refresh will use R2.2, at which point R1 should never be seen again. >>>>=20 >>>> The biggest issue that I see with a time-based grace period is that for= many offline tasks, a single refresh failure may be ignored by the client, a= nd it could be hours before the second refresh attempt using the older refre= sh token is made (depending on time of day and what these requests are being= used for), making the grace period low value in that case. >>>>=20 >>>>> On Tue, Oct 6, 2020 at 5:28 PM wrote: >>>>> Hey Aaron, >>>>>=20 >>>>> Auth0 does offer a configurable grace period, during which the =E2=80=9C= preceding=E2=80=9D token can be reused. >>>>>=20 >>>>> I am not 100% sure what we do in the exact scenario you described, and= I will double check for you, but here=E2=80=99s my intuition. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> The operation redeem(RT_n) should result in AT, RT_n+1. The grace peri= od just extends the time in which the operation can occur, but every operati= on should be idempotent. All repeats of that operation within the grace peri= od should have the same result, which means that every resulting RT is a rep= resentative of the RT_n+1 class, hence all valid at the same time. After the= grace period elapses, RT_n is invalid, and that=E2=80=99s it. >>>>>=20 >>>>> So, in your example I would consider RT1.1 and RT1.2 as equivalent, as= they are both representatives of the RT_n+1 equivalence class. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> It would be very hard to do otherwise, given that network operations a= ren=E2=80=99t guaranteed to be concluded in the order they were executed wit= hout semaphores, and above all the network failures the grace period is desi= gned to handle can apply to any of the requests, regardless of the order. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: OAuth On Behalf Of Aaron Parecki >>>>> Sent: Tuesday, October 6, 2020 3:06 PM >>>>> To: OAuth WG >>>>> Subject: [OAUTH-WG] Implementation questions around refresh token rota= tion >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Hi all, I have a couple questions for those of you who have implemente= d refresh token rotation... >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Have you included the option of a grace period on refresh token use, a= llowing multiple uses within some time window? I'm wondering because a grace= period where a refresh token may be used more than once would work around t= he problem that has been brought up, of a mobile app accidentally using a re= fresh token more than once during normal operation because different threads= are unable to coordinate between themselves. However that also kind of defe= ats the purpose since attacks within that grace period would be hard to dete= ct. I'm looking for an idea of where people have landed on that issue in pra= ctice. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> If you have implemented a grace period, then how do you handle expirin= g the additional refresh tokens that have been granted? For example, if RT "= R1" is used twice, resulting in new ATs "A1.1", "A1.2" and new RTs "R1.1" an= d "R1.2", what happens if "R1.2" is then later used? Would you invalidate "R= 1.1" at that point? If so, why, and if not, why not? >>>>>=20 >>>>> =20 >>>>>=20 >>>>> It would be most interesting to hear practical experience from people w= ho have already built refresh token rotation into a system. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Thanks! >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --- >>>>>=20 >>>>> Aaron Parecki >>>>>=20 >>>>> https://aaronparecki.com >>>>>=20 >>>>> =20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> --=20 >>> Dave Tonge >>>=20 >>>=20 >>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology L= imited which is authorised and regulated by the Financial Conduct Authority (= "FCA"). Moneyhub Financial Technology is entered on the Financial Services R= egister (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Tec= hnology is registered in England & Wales, company registration number 069097= 72. Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, R= egus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.=20 >>>=20 >>> DISCLAIMER: This email (including any attachments) is subject to copyrig= ht, and the information in it is confidential. Use of this email or of any i= nformation in it other than by the addressee is unauthorised and unlawful. W= hilst reasonable efforts are made to ensure that any attachments are virus-f= ree, it is the recipient's sole responsibility to scan all attachments for v= iruses. All calls and emails to and from this company may be monitored and r= ecorded for legitimate purposes relating to this company's business. Any opi= nions expressed in this email (or in any attachments) are those of the autho= r and do not necessarily represent the opinions of Moneyhub Financial Techno= logy Limited or of any other group company. >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 >=20 >=20 >=20 > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Li= mited which is authorised and regulated by the Financial Conduct Authority (= "FCA"). Moneyhub Financial Technology is entered on the Financial Services R= egister (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Tec= hnology is registered in England & Wales, company registration number 069097= 72. Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, R= egus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.=20 >=20 > DISCLAIMER: This email (including any attachments) is subject to copyright= , and the information in it is confidential. Use of this email or of any inf= ormation in it other than by the addressee is unauthorised and unlawful. Whi= lst reasonable efforts are made to ensure that any attachments are virus-fre= e, it is the recipient's sole responsibility to scan all attachments for vir= uses. All calls and emails to and from this company may be monitored and rec= orded for legitimate purposes relating to this company's business. Any opini= ons expressed in this email (or in any attachments) are those of the author a= nd do not necessarily represent the opinions of Moneyhub Financial Technolog= y Limited or of any other group company. >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-10B5E0BA-ADDD-444E-91D3-C837096880C6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Am 12.10.2020 um 09:04 schrieb Dave Tonge <= ;dave.tonge@momentumft.co.uk>:

=EF=BB=BF
Hi Neil=

 > refresh token rotation is better thought of as providing protection agai= nst insecure token storage on the client

I agree with your reasoning - and that was more the intent of what I sai= d. We've seen refresh token rotation used for confidential clients that have= secure storage (i.e. are run in a data center not on a mobile device) and i= t has caused problems with zero additional security benefits. 

Those are good examples of w= hy refresh token rotation should not be used if there are better ways availa= ble to protect refresh tokens from replay. Client authentication or sender c= onstrained refresh tokens are the better choice.


Dave
<= div class=3D"gmail_default">


On Mon, 12 Oct 2020 at 08:57,= Neil Madden <neil.madden@fo= rgerock.com> wrote:
I=E2=80=99m not sure I agre= e with this advice. Singling out private_key_jwt and tls_client_auth suggest= s that the problem is an attacker being able to eavesdrop on the refresh req= uest itself and then replay it. But if they are able to do that then they ca= n instead just steal the access tokens from the response.

I think refresh token rotation is better thought of as providing protection= against insecure token storage on the client (e.g. in browser localStorage)= . Both public and confidential clients are capable of creating secure connec= tions with TLS, but we assume that confidential clients (regardless of auth m= echanism) have access to secure storage - otherwise they shouldn=E2=80=99t b= e confidential clients in the first place.

I think t= he same reasoning applies here too - if a client has insecure storage then a= n attacker could just steal the access tokens instead. But I think the diffe= rence is that an attacker is more likely to gain temporary access to local s= torage (e.g. when the user goes to the bathroom and leaves their device unlo= cked) than they are to gain temporary access to eavesdrop on a connection. T= he kind of vulnerabilities that allow eavesdropping tend to be repeatable so= the attacker doesn=E2=80=99t need to steal a refresh token to ensure ongoin= g access, they can just steal the access tokens every time the client refres= hes.

That said, there are lots of vulnerabilities t= hat would give an attacker repeatable access to the client=E2=80=99s local s= torage - e.g. XSS - so refresh token rotation only catches a subset of possi= ble attacks.

=E2=80=94 Neil

On 12 Oct 2020, at 05:43, Dave Tonge= <dave.t= onge@momentumft.co.uk> wrote:

>=  Our goal is to p= revent cases where we lose the ability to Refresh a Token due to transient i= ssues (which have run the gamut from network problems to bad software update= s on the AS side).
We've seen this issu= e quite a bit and it's very frustrating. I would suggest that refresh token r= otation is not used for confidential clients that authenticate with private_= key_jwt or tls_client_auth. 

On Wed, 7 Oct 2020 at 00:57, Je= ff Craig <jeffcraig=3D40google.com@dmarc.ietf.org> wrote:
My experience i= s more from the Client side of the equation on this problem, but I do have s= ome thoughts. Our goal is to prevent cases where we lose the ability to Refr= esh a Token due to transient issues (which have run the gamut from network p= roblems to bad software updates on the AS side). Our use case also does all t= oken handling server-side, so our threat model is not the same as the mobile= application you described. There is a clear tradeoff in reducing user frict= ion with additional authorization events, and securing access.
The recommendation my team typically gives people building=  Authorization Servers with Refresh Token Rotation is to keep the old r= efresh token until they see the new one (which means that there are gen= erally two refresh tokens valid at any point in time, an unfortunate trade-o= ff). A more difficult, but potentially plausible implementation would be to h= old onto the older Refresh Token until the newly issued Access Token is used= (thus implying the refresh was successful on both sides).

We aren't trying to protect against multiple in-flight refreshes tho= ugh (we've done a LOT of work to attempt to remove that possibility in a glo= bally consistent manner), we're trying to protect against a network interrup= tion that prevents the first use of R1, so our assumption is that R2.1 was c= ompletely lost, and only R2.2 matters moving forward. Meaning: R1 is sent, A= /R2.1 is dropped in flight, R1 is sent again, A/R2.2 is returned and stored.= Since R1 was seen a second time, we recommend that R2.1 be ignored in futur= e. Next refresh will use R2.2, at which point R1 should never be seen again.=

The biggest issue that I see with a time-based gra= ce period is that for many offline tasks, a single refresh failure may be ig= nored by the client, and it could be hours before the second refresh attempt= using the older refresh token is made (depending on time of day and what th= ese requests are being used for), making the grace period low value in that c= ase.

On Tue, Oct 6, 2020 at 5:28 PM <vittorio.bertocci=3D40auth0.com@dmarc.ietf.o= rg> wrote:
=

Hey Aaron,

=

Auth0 does offer a configurable grace period, during w= hich the =E2=80=9Cpreceding=E2=80=9D token can be reused.

=

I am not 100% sure what we do in the exact scenario y= ou described, and I will double check for you, but here=E2=80=99s my intuiti= on.

 

The operation redeem(RT_n) should result in AT, RT_n+1. The g= race period just extends the time in which the operation can occur, but ever= y operation should be idempotent. All repeats of that operation within the g= race period should have the same result, which means that every resulting RT= is a representative of the RT_n+1 class, hence all valid at the same time. A= fter the grace period elapses, RT_n is invalid, and that=E2=80=99s it.

So, in your example I would consider RT1.= 1 and RT1.2 as equivalent, as they are both representatives of the RT_n+1 eq= uivalence class.

 

It would be very hard to do otherwise, given tha= t network operations aren=E2=80=99t guaranteed to be concluded in the order t= hey were executed without semaphores, and above all the network failures the= grace period is designed to handle can apply to any of the requests, regard= less of the order.

 <= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron Parecki=
Sent: Tuesday, October 6, 2020 3:06 PM
To: OAuth WG <= ;oauth@ietf.org><= br>Subject: [OAUTH-WG] Implementation questions around refresh token r= otation

 

Hi all, I have a couple questions for tho= se of you who have implemented refresh token rotation...

 

Have you included the option of a grace period on refresh token u= se, allowing multiple uses within some time window? I'm wondering because a g= race period where a refresh token may be used more than once would work arou= nd the problem that has been brought up, of a mobile app accidentally u= sing a refresh token more than once during normal operation because differen= t threads are unable to coordinate between themselves. However that also kin= d of defeats the purpose since attacks within that grace period would be har= d to detect. I'm looking for an idea of where people have landed on that iss= ue in practice.

&n= bsp;

If you have implemented a g= race period, then how do you handle expiring the additional refresh tokens t= hat have been granted? For example, if RT "R1" is used twice, resulting = ;in new ATs "A1.1", "A1.2" and new RTs "R1.1" and "R1.2", what happens if "R= 1.2" is then later used? Would you invalidate "R1.1" at that point? If so, w= hy, and if not, why not?

=  

It would be most i= nteresting to hear practical experience from people who have already built r= efresh token rotation into a system.

 

Thanks= !


=

---

Aaron Parecki

&= nbsp;

__________________= _____________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
=
Dave Tonge


Moneyhub Enterprise is a trading style of Moneyhub Finan= cial Technology Limited which is authorised and regulated by the Financial C= onduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Fi= nancial Services Register (FRN 809360) at https://register.fca.org.uk/. Mone= yhub Financial Technology is registered in England & Wales, company regi= stration number 06909772. Moneyhub Financial Technology Limited 2020 =C2=A9 M= oneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.=  

DIS= CLAIMER: This email (including any attachments) is subject to copyright, and= the information in it is confidential. Use of this email or of any informat= ion in it other than by the addressee is unauthorised and unlawful. Whilst r= easonable 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 e= xpressed in this email (or in any attachments) are those of the author and d= o not necessarily represent the opinions of Moneyhub Financial Technology Li= mited or of any other group company.


__________________= _____________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mail= man/listinfo/oauth





Moneyhub Enterprise is a trading style of Moneyhub Financial= Technology Limited which is authorised and regulated by the Financial Condu= ct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financ= ial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub= Financial Technology is registered in England & Wales, company registra= tion number 06909772. Moneyhub Financial Technology Limited 2020 =C2=A9 Mone= yhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.&nb= sp;

DISCLA= IMER: This email (including any attachments) is subject to copyright, and th= e 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 reas= onable efforts are made to ensure that any attachments are virus-free, it is= the recipient's sole responsibility to scan all attachments for viruses. Al= l calls and emails to and from this company may be monitored and recorded fo= r legitimate purposes relating to this company's business. Any opinions expr= essed in this email (or in any attachments) are those of the author and do n= ot necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.


_______________= ________________________________
OAuth mailing listOAuth@ietf.org
https://www.ietf.org/mailman/listinfo= /oauth
= --Apple-Mail-10B5E0BA-ADDD-444E-91D3-C837096880C6-- --Apple-Mail-B60855C8-B52A-4F7F-B465-5268C6AD998A Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBPgw ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wxggOpMIIDpQIBATCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgM B0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5w LkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAxMDEyMDkxNTE1WjAvBgkqhkiG9w0BCQQxIgQg QWOFU98K4e57p6ou5zQvNg8Zt9j+LwGj7pQqwHXZmfgwgbMGCSsGAQQBgjcQBDGBpTCBojCBjTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x IzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzCBtQYLKoZIhvcNAQkQ AgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UE AwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzICEGl8QiQdCJabMXrMOyB0X4Mw DQYJKoZIhvcNAQELBQAEggEAIwdla73NNjnIQBVFXcf0CTLzfqunHAkxScnYHmUfiKCpfJLF8V0Y SHozqHp33MK/B4ZDSPSudssotEB8oTQTlYTjfCZpBdgjWcrHQnPEri9tT7UOaj5w4jwpi8/5j9LJ kr5ZY+UN25rnDPAjNfvOn6Ca2Go5UpScsR7yXB6dtks2/Yqvq4z/yJBmiPOsdCzmF59wc33xBtil oHpsaR/HLDeMn1txJ7y11oMCD662hCxLICfAqNWBQSBBCyvrGz2zLtJxuGIvJbEQmgW0Rg2pVTeX uOPXoaujb6B4cN4fLZFBa1+K3HY/HiFhCJHNb6B68A08aPbRgYj6Kca5qrYK4QAAAAAAAA== --Apple-Mail-B60855C8-B52A-4F7F-B465-5268C6AD998A--