Subject: [OAUTH-WG] Working Group Last Call on "Symmetric Proof of Possession for the OAuth Authorization Code Grant"

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 26 Aug 2014 21:32:39 +0200

Hi all,

This is a Last Call for comments on the "Symmetric Proof of Possession
for the OAuth Authorization Code Grant" specification.

The document can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-spop/

Please have your comments in no later than September 9th.

Ciao
Hannes & Derek

---

From: Phil Hunt <[email-masked]>
Date: Tue, 26 Aug 2014 12:39:18 -0700

I am confused. We hummed to adopt the document not to go to last call.

Phil

@independentid
www.independentid.com
[email-masked]

On Aug 26, 2014, at 12:32 PM, Hannes Tschofenig <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Tue, 26 Aug 2014 15:46:53 -0400

Yes,  I haden’t anticipated going to last call right after being adopted as a WG document.

Is this some procedural thing that I am unaware of?

John B.

---

From: Mike Jones <[email-masked]>
Date: Tue, 26 Aug 2014 20:01:25 +0000

I'm confused too.  There hadn't been any discussion of any of the new documents going to last call that I can remember, either in Toronto, or on the list.

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Tuesday, August 26, 2014 12:47 PM
To: Phil Hunt
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Working Group Last Call on "Symmetric Proof of Possession for the OAuth Authorization Code Grant"

Yes,  I haden't anticipated going to last call right after being adopted as a WG document.

John B.

On Aug 26, 2014, at 3:39 PM, Phil Hunt <[email-masked]> wrote:

>> This is a Last Call for comments on the "Symmetric Proof of 
>> Possession for the OAuth Authorization Code Grant" specification.
>>

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 26 Aug 2014 20:35:25 +0000

Agreed, I'm guessing it was a clerical error with the IETF tools.

 -- Justin

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 27 Aug 2014 17:45:03 +0200

Based on the reaction from a few I thought I should add a few words
about this working group last call.

There is no requirement to wait a specific timeframe after a document
became a WG item to issue a working group last call.

In this specific case, the document was around for a while and I didn't
see a reason for not-finishing it as soon as possible.

Additionally, since the document deals with a security vulnerability
that is being exploited today I thought it might make sense to get the
attention from the group to review it.

Finally, it is also a fairly "simple" document (if there is something as
simple in this working group).

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Wed, 27 Aug 2014 12:40:09 -0400

OK that explains it. 

You are basically giving the authors and reviewers a hurry up as it is security related.

Nat and I will give it a higher priority then.

Nat and I would like feedback on it quickly then.

As you point out it is not a complex extension and has been deployed in a number of cases.

As long as we are clear that the authors aren’t trying to slip something through. (In this case:)

John B.

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 27 Aug 2014 20:44:38 +0000

Not all of us look at individual drafts, and thus I have not previously read this, but I did this morning and find that there are issues with the way the "code challenge" is specified as this requires pre negation of what/how that value was achieved and a large scale deployment that is almost impossible, if a JWK were used as the default this could eliminate some of the guess work and pre-negotiation work. 

I don't think it's ready for WGLC as there has been no discussion yet.

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, August 27, 2014 8:45 AM
To: [email-masked]
Subject: Re: [OAUTH-WG] Working Group Last Call on "Symmetric Proof of Possession for the OAuth Authorization Code Grant"

Based on the reaction from a few I thought I should add a few words about this working group last call.

There is no requirement to wait a specific timeframe after a document became a WG item to issue a working group last call.

In this specific case, the document was around for a while and I didn't see a reason for not-finishing it as soon as possible.

Additionally, since the document deals with a security vulnerability that is being exploited today I thought it might make sense to get the attention from the group to review it.

Finally, it is also a fairly "simple" document (if there is something as simple in this working group).

Ciao
Hannes

---

From: Brian Campbell <[email-masked]>
Date: Wed, 27 Aug 2014 15:27:06 -0600

There was a previous discussion (
http://www.ietf.org/mail-archive/web/oauth/current/msg12860.html and other
messages in the thread) about lengths where the general consensus seemed to
be that the length restriction should be on both the code_verifier and the
code_challenge parameter values.  And also discussed in terms of octets
rather than bytes. Those minor changes should be made as part of the WGLC
process.

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 28 Aug 2014 11:32:16 +0900

+1 

=nat via iPhone

Aug 28, 2014 6:27、Brian Campbell <[email-masked]> のメッセージ:

> There was a previous discussion (http://www.ietf.org/mail-archive/web/oauth/current/msg12860.html and other messages in the thread) about lengths where the general consensus seemed to be that the length restriction should be on both the code_verifier and the code_challenge parameter values.  And also discussed in terms of octets rather than bytes. Those minor changes should be made as part of the WGLC process.
> 
> 
> 
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 29 Aug 2014 01:00:04 +0000

Here's some feedback on the document.

First, while I believe that the document is a good first working group draft and this specification is important, it is not ready for last call, since there are open issues called out in the document that have not been discussed by the working group and aspects of the specification are incomplete.  I'll discuss those below.  There are also significant ambiguities in the document at present that could lead to non-interoperable implementations.  I believe that it would be more appropriate to bring the document to WGLC once these significant issues (and those that may be raised by other reviewers) have been addressed.

2.  Terminology - I would list "code challenge" before "code verifier" both because it is used first and because it's alphabetically first.

2.1 code verifier - Is this an octet sequence to be sent as-is (with the requirement for %-escaping octets representing non-url-safe characters) or as the base64url encoding of the octet sequence?

2.2 code challenge - Same question as above.  Then I would just say that the code challenge value is a function of the code verifier value and discuss the possible functions in its own section or subsection.

NOTE 1:  This should be discussed in the section about the transformation function.  Also, say here what criteria people might use to choose function.

NOTE 2:  Also fold this into the transformation function section.

3.2 Client registers its desired code challenge algorithm - A means of registering this algorithm using OAuth Dynamic Client Registration should be defined.  Use of this method should be optional.  Any metadata values defines should be registered in the appropriate registry.

3.4 Client sends the code challenge - Is the code challenge octet sequence value sent or the base64url encoding of it?

3.6  Client sends the code and the secret  - Is the code verifier octet sequence value sent or the base64url encoding of it?

4.1  OAuth Parameters Registry - The change controller should be "IESG".

5.  Security Considerations - The implications of choosing different kinds of transformation functions should be discussed.

I would recommend running the HTML output of xml2rfc through a grammar and spelling checker, as numerous grammar nits would be caught by doing so.

                                                                -- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, August 27, 2014 8:45 AM
To: [email-masked]
Subject: Re: [OAUTH-WG] Working Group Last Call on "Symmetric Proof of Possession for the OAuth Authorization Code Grant"

Ciao

Hannes

> [email-masked]<mailto:[email-masked]>

---

From: "Manger, James" <[email-masked]>
Date: Fri, 29 Aug 2014 15:03:54 +1000

Couple of comments on draft-ietf-oauth-spop-00:

The draft defines a nice little mechanism to link two requests: one from app-to-browser-to-server, the other from app-to-server.

1.
The spec defines the "bearer token" version of linking the requests: pick a random value and send it in both requests. The spec repeatedly hints that other "transformations" are possible (and even mentions one in a note), but it doesn't define enough to make these other ones interoperable.
I suggest just specifying the bearer version and dropping all the other text.
If we want another transform standardized later then we write another spec (which can use its own field names).

2.
Linking requests is orthogonal to whether or not the requests include a field called "code". I suggest changing the labels "code_challenge" and "code_verifier" to drop the "code" reference. Perhaps replace both with "session_id" ("sid" for short?).

3.
The spec is titled "Symmetric Proof of Possession ..." but defines a bearer mechanism, which you cannot really classify as proof-of-possession. Suggestion: change the title.

4.
The text is totally OAuth-centric, though the mechanism is not really limited to this case. It would be much nicer to describe the mechanism more generically (eg app running on a user's computer wanting to link two requests made to a server over different channels). The abstract (and the start of the introduction) should be comprehensible without having to know what the phrase "OAuth 2.0 public client" means. There would still be some OAuth-specific sections describing how the mechanism applies to the code flow (and to register a field in the IANA OAuth registry).

--
James Manger