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 protected]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, August 27, 2014 8:45 AM
To: [email protected]
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
On 08/26/2014 09:32 PM, Hannes Tschofenig wrote:
> 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
>
>
>
> _______________________________________________
> OAuth mailing list
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
