On #1, I know some have pushed for having the transformation options so I
don't know if dropping it will work. But, if not removed entirely, the
transformation stuff could definitely be deemphasized in favor of what will
be the most common case of the client sending a random string value on the
authorization request and then sending the same value on the token request.
On #2, there are already implementations and deployments of this so I'd
request that the parameter names not be changed.
On #3, I agree that the title is confusing/misleading. Perhaps, "Request
Correlation for the OAuth Authorization Code Grant" or something like that?
On #4, on one hand you are right. On the other hand, this is the OAuth WG
and this draft is addressing a very specific security issue in OAuth
deployments. Having it be OAuth-centric seems right given the circumstances.
On Thu, Aug 28, 2014 at 11:03 PM, Manger, James <
james.h.man...@team.telstra.com> wrote:
> 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
>
> _______________________________________________
> 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
