IETF Logo Mail Archive

Re: [OAUTH-WG] SPOP - code verifier requirements

Chuck Mortimore <cmortimore@salesforce.com> Wed, 15 October 2014 18:48 UTC

Return-Path: <cmortimore@salesforce.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FEC1A1B19 for <oauth@ietfa.amsl.com>; Wed, 15 Oct 2014 11:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 23cBIgSQ8cSD for <oauth@ietfa.amsl.com>; Wed, 15 Oct 2014 11:48:50 -0700 (PDT)
Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDE11A90E1 for <oauth@ietf.org>; Wed, 15 Oct 2014 11:48:48 -0700 (PDT)
Received: by mail-ob0-f179.google.com with SMTP id wp4so1598846obc.10 for <oauth@ietf.org>; Wed, 15 Oct 2014 11:48:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-type; bh=juA99J16l5EbSqgyDt60YRG2oOA43VF7ilJHp/etrjI=; b=b4U96+AElgnsc2r05sItRK1hbvYDCGHtybID0HmpS1CzpKaXaWH9c8QrThnuArLc9G HNoHJKN5HvbrgquwDcgfedtmK78MybOl3eP+pGGKXjY/CDzbZmu7N81Iv58+61h6AVgC p8kq4L5csLJ1Jn1KCnqs56DPB75lM9Nm5ydV74moGf+dVC3irVyd/ukP/RiuMuVHSdP2 gu9Howcw4pTW2/ZLaBeZuhh1p8ZXZ+iyA6yAx/6C0i/qnrYuQAXxijv1YFya7WMSkQtf JrfbYsx2fk5O+97HzvjoO+jhth/ojFgdbIT/nH8449YY893cBXGtsgjciEL6AGmW8coR FmJg==
X-Gm-Message-State: ALoCoQnJdJoCQ4qhp7g/GsYZohl7MQiRQ0gMnqi+7WulWW8frYf5nlGPpj9+RD/TPNxfgqhvaDDD
X-Received: by 10.202.191.194 with SMTP id p185mr3957150oif.63.1413398928376; Wed, 15 Oct 2014 11:48:48 -0700 (PDT)
From: Chuck Mortimore <cmortimore@salesforce.com>
Mime-Version: 1.0 (1.0)
References: <20141014182611.dd6598cc163e9c640d4167fd@nri.co.jp> <CA+wnMn9Fs3FsNKN2FP_2c=NbeFepgjJaK=+QE2U8--uaLNvuZQ@mail.gmail.com> <A2C25784-D36C-4783-B541-D1ADF621FCDE@gmail.com>
In-Reply-To: <A2C25784-D36C-4783-B541-D1ADF621FCDE@gmail.com>
Date: Wed, 15 Oct 2014 11:48:47 -0700
Message-ID: <-1123724406662361791@unknownmsgid>
To: Nat Sakimura <sakimura@gmail.com>
Content-Type: multipart/alternative; boundary="001a113d6a520d5f6105057a95ef"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/GZA-81du4LHeaGAAE2xffHEzOoU
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] SPOP - code verifier requirements
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Oct 2014 18:48:52 -0000

We're actually debating it internally.   It seems easiest to just encode
the binary code up front.   Any issue with that?

- cmort

On Oct 15, 2014, at 8:32 AM, Nat Sakimura <sakimura@gmail.com> wrote:

Thanks.

So, to be clear, are you base64url encoding when sending it over the wire
or is your code verifier is created by base64url encoding the binary value
so that you do not need to encode it when sending it over?

=nat via iPhone

Oct 16, 2014 00:27、Chuck Mortimore <cmortimore@salesforce.com> のメッセージ:

We went with base64url in our implementation

On Tue, Oct 14, 2014 at 2:26 AM, Nat Sakimura <n-sakimura@nri.co.jp> wrote:

> In his mail, Mike asked whether code verifier is
> a value that is sendable without trnasformation
> as a http parameter value, or if it needs to be
> % encoded when it is being sent.
>
> We have several options here:
>
> 1) Require that the code verifier to be a base64url encoded string of a
> binary random value.
>
> 2) Let code verifier to be a binary string and require it to be
> either % encoded or base64url encoded when it is sent.
> In this case, which encoding should we use?
>
> 3) require the code verifier to be conform to the following ABNF:
> code_verifier = 16*128unreserved
> unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
>
> Which one do you guys prefer?
>
> Nat
>
> --
> Nat Sakimura (n-sakimura@nri.co.jp)
> Nomura Research Institute, Ltd.
>
> PLEASE READ:
> The information contained in this e-mail is confidential and intended for
> the named recipient(s) only.
> If you are not an intended recipient of this e-mail, you are hereby
> notified that any review, dissemination, distribution or duplication of
> this message is strictly prohibited. If you have received this message in
> error, please notify the sender immediately and delete your copy from your
> system.
>
> _______________________________________________
> 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

v2.23.0 | Report a Bug | By Email