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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
