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 DB530120018 for ; Mon, 6 Jan 2020 14:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 Lr6BW6kO1biP for ; Mon, 6 Jan 2020 14:22:21 -0800 (PST) Received: from mail-yw1-xc33.google.com (mail-yw1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (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 45EF612084C for ; Mon, 6 Jan 2020 14:22:21 -0800 (PST) Received: by mail-yw1-xc33.google.com with SMTP id i190so22569247ywc.2 for ; Mon, 06 Jan 2020 14:22:21 -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=ISmWmBnjnP3e60Q32jKYiqCMch99wZnFXzu1TgkJ6mo=; b=m03yS4GnOmOtuzbpbIVcYksZSDULpL1TVeXyh+K8aeDH4h7coY95oD+YZhLldCqmaZ SzALz6VPLx1NjkBxUaginRMce+kPR4SaWe5r9TMyiT5WFVYriqO/QvHJALcAqsNNDSjo FE8L5lA/SFjeDj5krd2DLWwZHVCeS8yUEUO2x6/5C/cGjvWGXWA+1ELTMVeYUFI6yDnu kE1/VKTegY9jbSUWFk1wvJyicSx2oxhPVQQcrozXYgVUJ/PPr/4lTkQvcrc4oTuvBKX8 nJoU40IHjvlfR3MPSsvZHBFI114rJgns1bIuUXysggwuJXqgEQY0DP7B3IOuwzbC/LEj j2mQ== 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=ISmWmBnjnP3e60Q32jKYiqCMch99wZnFXzu1TgkJ6mo=; b=qOjA3V2p4FhV2gtK5T9VDZL7E49BbhutxsiCHvh/ReGsuLg5ezeetcS5qoVCmBid32 jCzMx0k6UjTlDyu6EtEyKRi20fhmgLHC/abEzFet9UhfXYUPUau3nc6WuVWi/H2mxr8/ q8w4TrbQFS2TkveLfzAnr0MWsD2UunuL/dnMTU6+f/Hw30VRo2iaGPQwxnd6rotsnrkD ZcgrLk1HjKzX3FBYIl9bWhGa1GMUBQmH+TZZARQXtbxjYIhVUhVA6N2sQl2lIwXhElN9 /WBIEycsmB8qlyMzpW9wWKU9Xm44KqrIKhhi0WcWJuZ3f/CR0CHtW8jj1/qJLne/pXEv rymg== X-Gm-Message-State: APjAAAXgo6lqtLMfIgvSHPgny0hPxfIuqWKeBi6N+/7vwaCw4z0zwWW8 /tZKLBGwr6BwJ2vkbNG7r+EB2bNgke9AM+dakA== X-Google-Smtp-Source: APXvYqzDwzPgc2TAADv4W+8d9Dm8T/1bYbWHGFBVNzBCYje99K2jRZldGQDQNMjG6aD2FQYh8eGbOQcbTkYE9b0+YEE= X-Received: by 2002:a81:b604:: with SMTP id u4mr80402087ywh.301.1578349340297; Mon, 06 Jan 2020 14:22:20 -0800 (PST) MIME-Version: 1.0 References: <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com> <801AFC59-B94A-4C9E-A44D-60F4EF6F4EC2@forgerock.com> <38C69B8C-905F-46F1-88BB-016CF7DE2952@amazon.com> In-Reply-To: <38C69B8C-905F-46F1-88BB-016CF7DE2952@amazon.com> From: Filip Skokan Date: Mon, 6 Jan 2020 23:22:09 +0100 Message-ID: To: "Richard Backman, Annabelle" Cc: Neil Madden , Brian Campbell , Dave Tonge , oauth , Nat Sakimura Content-Type: multipart/alternative; boundary="000000000000c29085059b801774" Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR metadata 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, 06 Jan 2020 22:22:24 -0000 --000000000000c29085059b801774 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We've been discussing making the following change to the language The AS SHOULD validate the request in the same way as at the authorization > endpoint. The AS MUST ensure that all parameters to the authorization > request are still valid at the time when the request URI is used. > This would allow the PAR endpoint to simply stash the encrypted request object instead of decrypting and validating it. All within the bounds of "SHOULD - We=E2=80=99d like you to do this, but we can=E2=80=99t always req= uire it". This supports "light weight PAR" implementation rather than introducing the unnecessary complexity in the form of a second JWKS. Best, *Filip* On Mon, 6 Jan 2020 at 23:00, Richard Backman, Annabelle wrote: > The issue isn=E2=80=99t that the PAR endpoint needs access to one specifi= c request > object decryption key that could reasonably be shared across AS endpoints= , > but that it actually needs access to the private keys for all encryption > public keys in the JWK set pointed to by the AS=E2=80=99s jwks_uri metada= ta > property. Since there is no way to designate one particular key as the on= e > to use for encrypting request objects, clients may reasonably use any > encryption public key in the JWK set to encrypt a request object. As one > example of how this could expose sensitive data to the PAR endpoint, if t= he > PAR endpoint has all the decryption keys for the keys in the AS=E2=80=99s= JWK set, > it would be able to decrypt ID Tokens sent in id_token_hint request > parameters. As more and more use cases develop for encrypting blobs for t= he > AS, this issue will only get worse. > > > > The PAR endpoint can=E2=80=99t simply stash the encrypted request object,= as it is > required to verify the request, according to =C2=A72.1: > > > > The AS MUST process the request as follows: > > > > ... > > > > 3. The AS MUST validate the request in the same way as at the > > authorization endpoint. ... > > > > This language needs to be more flexible, IMHO, to allow for lightweight > PAR endpoints that may not have the information or authority needed to > perform all the validation that happens at the authorization endpoint. I > need to think about this more before I can say if it would adequately > address my concerns, but it=E2=80=99d be a good start and makes sense in = its own > right. > > > > I think it=E2=80=99s pretty risky for us to base decision on an assumptio= n that no > one is going to need or want to encrypt pushed request objects, > particularly when they=E2=80=99re JWTs, and JWTs have well established su= pport for > encryption, and encrypted JWTs are supported by pass-by-value in OIDC and > draft-ietf-oauth-jwsreq. But if you insist, here are a few examples for w= hy > someone might want to do this: > > 1. The request object is passed by reference, and accessible on the > public Internet. > 2. The request object contains sensitive transaction-related data in > RAR parameters that the client=E2=80=99s authN/authZ stack doesn=E2=80= =99t need to have > access to. > 3. The AS requires request object encryption to minimize exposure to > the hosted PAR endpoint service it uses. > 4. #2, but the threat vector is gaps in end-to-end TLS. > 5. Any of the above, but the concern is message integrity, and the AS > requires requested objects to be encrypted for confidentiality and > integrity protection and does not support signed request objects. > > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Neil Madden > *Date: *Monday, January 6, 2020 at 6:29 AM > *To: *Brian Campbell > *Cc: *"Richard Backman, Annabelle" , Nat Sakimura < > nat@sakimura.org>, Dave Tonge , Torsten > Lodderstedt , oauth > *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata > > > > Agreed. > > > > In addition, I'm not sure why the PAR endpoint would need access to the > decryption keys at all. If you're using encrypted request objects then th= e > PAR endpoint receives an encrypted JWT and then later makes the same (sti= ll > encrypted) JWT available to the authorization endpoint. If the PAR endpoi= nt > is doing any kind of decryption or validation on behalf of the > authorization endpoint then they are clearly not in separate trust > boundaries. > > > > -- Neil > > > > > > On 6 Jan 2020, at 13:57, Brian Campbell < > bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote: > > > > I really struggle to see the assumption that an entity be able to use the > same key to decrypt the same type of message ultimately intended for the > same purpose as an artificial limit. The same general assumption > underlies everything else in OAuth/OIDC (Vladimir's post points to some b= ut > not all examples of such). There's no reason for PAR to make a one-off > exception. And should there be some deployment specific reason that truly > requires that kind of isolation, there are certainly implementation optio= ns > that aren't compatibility-breaking. And having said all that, I'm honestl= y > a little surprised anyone is thinking much about encrypted request object= s > with PAR as, at least with my limited imagination, there's not really a > need for it. > > > > > > > > > > > > > > > > > > On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > PAR introduces an added wrinkle for encrypted request objects: the PAR > endpoint and authorization endpoint may not have access to the same > cryptographic keys, even though they're both part of the "authorization > server." Since they're different endpoints with different roles, it's > reasonable to put them in separate trust boundaries. There is no way to > support this isolation with just a single "jwks_uri" metadata property. > > The two options that I see are: > > 1. Define a new par_jwks_uri metadata property. > 2. Explicitly state that this separation is not supported. > > I strongly perfer #1 as it has a very minor impact on deployments that > don't care (i.e., they just set par_jwks_uri and jwks_uri to the same > value) and failing to support this trust boundary creates an artificial > limit on implementation architecture and could lead to > compatibility-breaking workarounds. > > =E2=80=93 > Annabelle Richard Backman > AWS Identity > > > On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" < > oauth-bounces@ietf.org on behalf of torsten=3D > 40lodderstedt.net@dmarc.ietf.org> wrote: > > Hi Filip, > > > On 31. Dec 2019, at 16:22, Filip Skokan wrote: > > > > I don't think we need a *_auth_method_* metadata for every endpoint > the client calls directly, none of the new specs defined these (e.g. devi= ce > authorization endpoint or CIBA), meaning they also didn't follow the sche= me > from RFC 8414 where introspection and revocation got its own metadata. In > most cases the unfortunately named `token_endpoint_auth_method` and its > related metadata is what's used by clients for all direct calls anyway. > > > > The same principle could be applied to signing (and encryption) > algorithms as well. > > > > This I do not follow, auth methods and their signing is dealt with > by using `token_endpoint_auth_methods_supported` and > `token_endpoint_auth_signing_alg_values_supported` - there's no encryptio= n > for the `_jwt` client auth methods. > > Unless it was meant to address the Request Object signing and > encryption metadata, which is defined and IANA registered by OIDC. PAR on= ly > references JAR section 6.1 and 6.2 for decryption/signature validation an= d > these do not mention the metadata (e.g. request_object_signing_alg) anymo= re > since draft 07. > > Dammed! You are so right. Sorry, I got confused somehow. > > > > > PS: I also found this comment related to the same question about > auth metadata but for CIBA. > > Thanks for sharing. > > > > > Best, > > Filip > > thanks, > Torsten. > > > > > > > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > Hi all, > > > > Ronald just sent me an email asking whether we will define metadata > for > > > > pushed_authorization_endpoint_auth_methods_supported and > > pushed_authorization_endpoint_auth_signing_alg_values_supported. > > > > The draft right now utilises the existing token endpoint > authentication methods so there is basically no need to define another > parameter. The same principle could be applied to signing (and encryption= ) > algorithms as well. > > > > What=E2=80=99s your opinion? > > > > best regards, > > Torsten. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > 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 > --000000000000c29085059b801774 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We've been discussing making the following=C2=A0c= hange to the language

The AS SHOULD validate the request in the same way as at t= he authorization endpoint. The AS MUST ensure that all parameters to the au= thorization request are still valid at the time when the request URI is use= d.

This would allow the PAR endpoint to= simply stash the encrypted request object instead of decrypting and valida= ting it. All within the bounds of "SHOULD -=C2=A0We=E2=80=99d like you= to do this, but we can=E2=80=99t always require it". This supports &q= uot;light weight PAR" implementation rather than introducing the unnec= essary complexity in the form of a second JWKS.

Best,
Filip


On Mon, 6 Jan 2020 a= t 23:00, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
=

The issue isn=E2=80=99t that the PAR endpoint needs = access to one specific request object decryption key that could reasonably = be shared across AS endpoints, but that it actually needs access to the pri= vate keys for all encryption public keys in the JWK set pointed to by the AS=E2=80=99s jwks_uri metadata property. Sin= ce there is no way to designate one particular key as the one to use for en= crypting request objects, clients may reasonably use any encryption public = key in the JWK set to encrypt a request object. As one example of how this could expose sensitive data to the PAR = endpoint, if the PAR endpoint has all the decryption keys for the keys in t= he AS=E2=80=99s JWK set, it would be able to decrypt ID Tokens sent in id_t= oken_hint request parameters. As more and more use cases develop for encrypting blobs for the AS, this issue will on= ly get worse.

=C2=A0

The PAR endpoint can=E2=80=99t simply stash the encr= ypted request object, as it is required to verify the request, according to= =C2=A72.1:

=C2=A0

The AS MUST pr=
ocess the request as follows:
=C2=A0<=
u>
...<=
/u>
=C2=A0<=
u>
3.=C2=A0 The A=
S MUST validate the request in the same way as at the<=
/pre>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=
=A0=C2=A0=C2=A0authorization endpoint. ...


=C2=A0


This language needs to be more flexible, IMHO, to al=
low for lightweight PAR endpoints that may not have the information or auth=
ority needed to perform all the validation that happens at the authorizatio=
n endpoint. I need to think about
 this more before I can say if it would adequately address my concerns, but=
 it=E2=80=99d be a good start and makes sense in its own right.


=C2=A0


I think it=E2=80=99s pretty risky for us to base dec=
ision on an assumption that no one is going to need or want to encrypt push=
ed request objects, particularly when they=E2=80=99re JWTs, and JWTs have w=
ell established support for encryption, and encrypted
 JWTs are supported by pass-by-value in OIDC and draft-ietf-oauth-jwsreq. B=
ut if you insist, here are a few examples for why someone might want to do =
this:


    

  1. The request object is passed by reference, and accessible on the =
public Internet.
  2. The request object contains se=
nsitive transaction-related data in RAR parameters that the client=E2=80=99=
s authN/authZ stack doesn=E2=80=99t need to have access to.
  3. The AS requires request object encryption to minimize exposure=
 to the hosted PAR endpoint service it uses.
  4. #2=
, but the threat vector is gaps in end-to-end TLS.
  5. Any of the above, but the concern is message integrity, and the AS requ=
ires requested objects to be encrypted for confidentiality and integrity pr=
otection and does not support signed
 request objects.


=C2=A0




=E2=80=93=C2=A0


Annabelle Richard Bac=
kman


AWS Identity




=C2=A0


=C2=A0




From: =
Neil Madden <neil.madden@forge=
rock.com>

Date: Monday, January 6, 2020 at 6:29 AM

To: Brian Campbell <bcampbell@pingidentity.com>

Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, Nat Sakimu=
ra <nat@sakimura.o=
rg>, Dave Tonge <dave.tonge@moneyhub.com>, Torsten Lodderstedt <torsten@lodderstedt=
.net>, oauth <oauth@ietf.org>

Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata






=C2=A0




Agreed. 




=C2=A0






In addition, I'm not sure why the PAR endpoint w=
ould need access to the decryption keys at all. If you're using encrypt=
ed request objects then the PAR endpoint receives an encrypted JWT and then=
 later makes the same (still encrypted) JWT
 available to the authorization endpoint. If the PAR endpoint is doing any =
kind of decryption or validation on behalf of the authorization endpoint th=
en they are clearly not in separate trust boundaries.






=C2=A0






-- Neil






=C2=A0















On 6 Jan 2020, at 13:57, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:=





=C2=A0








I really struggle to see the assumption that an enti=
ty be able to use the same key to decrypt the same type of message ultimate=
ly intended for the same purpose as an artificial limit. The same general a=
ssumption =C2=A0 underlies everything else
 in OAuth/OIDC (Vladimir's post points to some but not all examples of =
such). There's no reason for PAR to make a one-off exception. And shoul=
d there be some deployment specific reason that truly requires that kind of=
 isolation, there are certainly implementation
 options that aren't compatibility-breaking. And having said all that, =
I'm honestly a little surprised anyone is thinking much about encrypted=
 request objects with PAR as, at least with my limited imagination, there&#=
39;s not really a need for it.







=C2=A0






=C2=A0






=C2=A0






=C2=A0






=C2=A0






=C2=A0






=C2=A0






=C2=A0






On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Anna=
belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:






PAR introduces an added wrinkle for encrypted reques=
t objects: the PAR endpoint and authorization endpoint may not have access =
to the same cryptographic keys, even though they're both part of the &q=
uot;authorization server." Since they're different
 endpoints with different roles, it's reasonable to put them in separat=
e trust boundaries. There is no way to support this isolation with just a s=
ingle "jwks_uri" metadata property.



The two options that I see are:



1. Define a new par_jwks_uri metadata property.

2. Explicitly state that this separation is not supported.



I strongly perfer #1 as it has a very minor impact on deployments that don&=
#39;t care (i.e., they just set par_jwks_uri and jwks_uri to the same value=
) and failing to support this trust boundary creates an artificial limit on=
 implementation architecture and could
 lead to compatibility-breaking workarounds.



=E2=80=93 

Annabelle Richard Backman

AWS Identity





On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" &l=
t;oauth-bounces=
@ietf.org on behalf of torsten=3D40lodderstedt.net@dmarc.ietf.org>
 wrote:



=C2=A0 =C2=A0 Hi Filip, 



=C2=A0 =C2=A0 > On 31. Dec 2019, at 16:22, Filip Skokan <panva.ip@gmail.com> wrot=
e:

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > I don't think we need a *_auth_method_* metadata for=
 every endpoint the client calls directly, none of the new specs defined th=
ese (e.g. device authorization endpoint or CIBA), meaning they also didn=
9;t follow the scheme from RFC 8414 where introspection
 and revocation got its own metadata. In most cases the unfortunately named=
 `token_endpoint_auth_method` and its related metadata is what's used b=
y clients for all direct calls anyway.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > The same principle could be applied to signing (and encr=
yption) algorithms as well.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > This I do not follow, auth methods and their signing is =
dealt with by using `token_endpoint_auth_methods_supported` and `token_endp=
oint_auth_signing_alg_values_supported` - there's no encryption for the=
 `_jwt` client auth methods.


=C2=A0 =C2=A0 > Unless it was meant to address the Request Object signin=
g and encryption metadata, which is defined and IANA registered by OIDC. PA=
R only references JAR section 6.1 and 6.2 for decryption/signature validati=
on and these do not mention the metadata (e.g.
 request_object_signing_alg) anymore since draft 07.



=C2=A0 =C2=A0 Dammed! You are so right. Sorry, I got confused somehow. 



=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > PS: I also found this comment related to the same questi=
on about auth metadata but for CIBA.



=C2=A0 =C2=A0 Thanks for sharing. 



=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > Best,

=C2=A0 =C2=A0 > Filip



=C2=A0 =C2=A0 thanks,

=C2=A0 =C2=A0 Torsten. 



=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt <torsten@lodderst=
edt.net> wrote:

=C2=A0 =C2=A0 > Hi all,

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > Ronald just sent me an email asking whether we will defi=
ne metadata for 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > pushed_authorization_endpoint_auth_methods_supported and=


=C2=A0 =C2=A0 > pushed_authorization_endpoint_auth_signing_alg_values_su=
pported.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > The draft right now utilises the existing token endpoint=
 authentication methods so there is basically no need to define another par=
ameter. The same principle could be applied to signing (and encryption) alg=
orithms as well.


=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > What=E2=80=99s your opinion?

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > best regards,

=C2=A0 =C2=A0 > Torsten.







_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth








CONFIDENTIALITY=
 NOTICE: This email may contain confidential and privileged material for th=
e sole use of the intended recipient(s). Any review,
 use, distribution or disclosure by others is strictly prohibited..=C2=A0 I=
f you have received this communication in error, please notify the sender i=
mmediately by e-mail and delete the message and any file attachments from y=
our computer. Thank you.____________________________________=
___________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth








=C2=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000c29085059b801774--