Re: [OAUTH-WG] draft-ietf-oauth-spop-10: Your feedback needed.

Torsten Lodderstedt <> Mon, 02 March 2015 18:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 324DC1A88AC for <>; Mon, 2 Mar 2015 10:22:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.151
X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AQ41mPWrAvxF for <>; Mon, 2 Mar 2015 10:21:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4BEAB1A88AD for <>; Mon, 2 Mar 2015 10:21:55 -0800 (PST)
Received: from [] (helo=[]) by with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <>) id 1YSUyX-0007WF-90; Mon, 02 Mar 2015 19:21:53 +0100
Message-ID: <>
Date: Mon, 02 Mar 2015 19:21:49 +0100
From: Torsten Lodderstedt <>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Hannes Tschofenig <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------070404010201090407020709"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10: Your feedback needed.
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Mar 2015 18:22:01 -0000

Hi Hannes,

Am 02.03.2015 um 16:31 schrieb Hannes Tschofenig:
> Hi all,
> I am trying to finalize my work on the shepherd write-up of
> draft-ietf-oauth-spop.
> Unfortunately, there are still some outstanding issues:
> 1. S256 as a mandatory-to-implement code challenge method
> (by the Authorization Server)
> Currently, S256 is MTI but implementations do not use S256 (yet).
> Hence, we have very few (maybe not even a single) implementation
> that is in conformance with the specification at the moment.
> Does the group see a problem with this choice of MTI
> (or lack of conformance)?

As already indicated on the list: The original reason to invent spop was 
to prevent malicous apps, which intercepted the redirect back to the 
legitimate app and that way impersonated the user (see section 1). In my 
opinion, "plain" fullfils this goal. I therefore don't see a need (or 
justification) to make S256 MTI.

The security considerations sections says:

"If the "plain" method is used,
    there is a chance that it will be observed by the attacker on the

Under which circumstances is an attacker supposed to observe the 
challenge on the device? And if the attacker is able to observe the URLs 
in an embedded or the system browser, isn't this attacker most likely 
capable of observing password input in the same browser? In this case, 
we should rather be concerned regarding the user's password then 
anything else.

kind regards,

> 2. Naveen Agarwal has not provided his confirmation that any and
> all appropriate IPR disclosures required for full conformance
> with the provisions of BCP 78 and BCP 79 have already been filed.
> Without his confirmation I cannot finalize my shepherd write-up.
> 3. Normative language regarding code verifier randomness
> We had a discussion about the language used to describe what
> implementations need to provide in terms of randomness of the
> code verifier. Here is the discussion thread:
> Ultimately, the issue boiled down to the following sentence and
> the use of 'MUST' vs. 'SHOULD':
> "the code verifier SHOULD have enough entropy to make it
> impractical to guess the value"
> It would be good to know whether the group objects using MUST
> instead of SHOULD to enhance security.
> Ciao
> Hannes
> _______________________________________________
> OAuth mailing list