From nobody Tue Oct 6 23:10:24 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 6E9853A1128 for ; Tue, 6 Oct 2020 23:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 lBtp54Idw9cK for ; Tue, 6 Oct 2020 23:10:20 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 16D383A170A for ; Tue, 6 Oct 2020 23:10:05 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id y20so1163875iod.5 for ; Tue, 06 Oct 2020 23:10:05 -0700 (PDT) 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=2DmJK6ngtQcWSuFSEti+ZBBC815yXOzdLE2weXj9J8c=; b=oKrzpqczddGOMavS2NF+pXwdQkstbjFpI5ShGniG8GDdKb4txvxWscHux3+mI9deSS 8hzphFXPAFHVdtkCd1kUqsQL4yxVqGDl3eiUWCUwzzdcxy91Iq70dslB/xIbZEYjRlTN EKNZ4PibMWlWuLlsCBKb+CQF5BjxzJWDn1+hdKoSjkV/+iWubXTobOKSFhauJQcmJ0US ZUp3srVyb5UrcJFDgT6nanjusd68gnPM12+bUixfP5loHvOv/UUJ81xWqX+0d82xD0JZ p4IJ7ARYXbEtzdlZsaGw/37ML0JofZptrsYVCugEI3CVF5IxMN3DUpSiKlxVAzQhl1oh DePg== 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=2DmJK6ngtQcWSuFSEti+ZBBC815yXOzdLE2weXj9J8c=; b=gwsNxDXOE7uFkmjyIArTD/W2UQMVqkHIkI1OQz65nMxw+Nh4VsMm4rag6GgulePwmS F9QnSui7OoHbD45pj6R1THvpQ/jb/5xAQOmVpmKaE706lhssaEz2XEKEzX/DbJhLXeRs UMFj8MYVnc1H+4iC6xyOSYenZzZ5M4xj2eLFDtnVcrHLfzHr8SosczaAnBsCZOMNK/pF SJ85RUB67KZZeJNxDqQM7g9jEE5uwP9WSwHR4JIiEFv+eFHvuu4pu5RHUphlgQNGXatv 1toVdeDATyyoo0ID2aV/AcdxbCTZxIpNMncynJTDDiZR5dS88M/D4FiAzaXJRbpRclNN UEsw== X-Gm-Message-State: AOAM531jHlgGDBsHFwOk2vbjAI+3f4dwOkFn4GsYdt0+xokAnvOCVS7A Z3+t/AsFwDwMQfdxS6bffz9WsrgJJuOAVBG9jWxf7o4E X-Google-Smtp-Source: ABdhPJwlOpyQkJ5KHugaiGrrtJMrR2Z+K/RMe26KAy1emYminVRpqo8XAUm9jvmhYmtrGdX15O0V+l0p8zwoy/dKeVI= X-Received: by 2002:a5e:cb43:: with SMTP id h3mr1156056iok.65.1602051004183; Tue, 06 Oct 2020 23:10:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Janak Amarasena Date: Wed, 7 Oct 2020 11:39:28 +0530 Message-ID: To: Aaron Parecki Cc: oauth Content-Type: multipart/alternative; boundary="00000000000004379e05b10e9183" Archived-At: Subject: Re: [OAUTH-WG] JSON based access token requests for OAuth 2.1 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: Wed, 07 Oct 2020 06:10:22 -0000 --00000000000004379e05b10e9183 Content-Type: text/plain; charset="UTF-8" Hi Aaron, Let me clarify a bit. What I meant was the spec does not make it mandatory to use x-www-form-urlencoded I am stating this as I did not see any clause with the word "MUST" with regard to this. And also what I was asking was not to change using x-www-form-urlencoded to json. More like about the possibility of adding an example of how the parameters should be used if the request is sent in JSON format like shown in Justin's draft. This will in turn imply JSON formatted requests are also acceptable and to anyone who wants to support this media type has guidance. Best Regards, Janak Amarasena On Tue, Oct 6, 2020 at 8:40 PM Aaron Parecki wrote: > The spec does clearly require form-encoded POST requests to the token > endpoint, it's not just an implication. The requests made include simple > key/value pairs so there's nothing really gained by making this a JSON > post. Changing that at this point would be a drastic breaking change to > pretty much all existing code for very little benefit if any. > > That said, Justin Richer did already write up a draft exploring this > topic, but it hasn't shown much interest in the group yet. > > https://www.ietf.org/id/draft-richer-oauth-json-request-00.html > > Aaron > > > > > > > On Tue, Oct 6, 2020 at 7:18 AM Janak Amarasena > wrote: > >> Hi All, >> >> As per my understanding OAuth 2(RFC6749) doesn't mandate any specific >> media type to be used in the access token request. The spec implies >> application/x-www-form-urlencoded should be used. Since the media type >> application/json is very popular and widely used now, any thoughts on >> referencing the use of this as well for access token requests? >> >> Best Regards, >> Janak Amarasena >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > -- > --- > Aaron Parecki > https://aaronparecki.com > > --00000000000004379e05b10e9183 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Aaron,

Let me clarify a bit. What I = meant was the spec does not make it mandatory to use=C2=A0x-www-form= -urlencoded I am stating this as I did not see any clause with the w= ord "MUST" with regard to this. And also what I was asking=C2=A0w= as not to change using=C2=A0x-www-form-urlencoded=C2=A0to jso= n. More like about the possibility of adding an example of how the paramete= rs=C2=A0should be used if the request is sent in JSON format like shown in = Justin's draft. This will in turn imply JSON formatted requests are als= o acceptable and to anyone who wants to support this media type has guidanc= e.

Best Regards,
Janak Amarasena

On= Tue, Oct 6, 2020 at 8:40 PM Aaron Parecki <aaron@parecki.com> wrote:
The spec does= clearly require form-encoded POST requests to the token endpoint, it's= not just an implication. The requests made include simple key/value pairs = so there's nothing really gained by making this a JSON post. Changing t= hat at this point would be a drastic breaking change to pretty much all exi= sting code for very little benefit if any.

That said, Justin Richer did already write up a draft ex= ploring this topic, but it hasn't shown much interest in the group yet.=

Aaron






On Tue, Oct 6, 2020 at 7:18 AM Janak Amarasen= a <janakama36= 0@gmail.com> wrote:
Hi All,

As per my understand= ing OAuth 2(RFC6749) doesn't mandate any specific media type to be used= in the access token request. The spec implies=C2=A0application/x-www= -form-urlencoded=C2=A0should be used. Since the media type=C2= =A0application/json=C2=A0is very popular and widely used now, any thoughts on refere= ncing the use of this as well for access token requests?

Best Regards,
Janak Amarasena
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
---<= /div>Aaron Parecki

--00000000000004379e05b10e9183--