> Are the tokens used in the examples long enough? I don't want the examples to demonstrate poor choice of byte count.
No. I found the following example values in draft 16. Client secret: gX1fBat3bV (10 chars, 60 bits) Code: i1WsRn1uB1 (10 chars, 60 bits) Access token: SlAV32hkKG (10 chars, 60 bits) Access token: FJQbwq9 ( 7 chars, 48 bits) Access token: 7Fjfp0ZBr1KtDRbnfVdmIw (22 chars, 132 bits, bearer token) Access token: h480djs93hd8 (12 chars, 72 bits, MAC id) Refresh token: 8xLOxBtZp8 (10 chars, 60 bits) Refresh token: n4E9O119d ( 9 chars, 54 bits) User password: A3ddj3w ( 7 chars, ? bits, user-chosen) 128 bits of entropy would be a good choice for most values. That is equivalent to 22 random base64 chars, as per longest example above. That is a minimum mentioned in draft-lodderstedt-oauth-security. Using 22-char values throughout the spec probably doesn't harm readability much as most of the examples already wrap over multiple lines (it might even help by wrapping more parameter names to the start of lines). The example user password is long enough. Curiously the secrets, codes, and tokens all look like base64-encoded values - but almost none are actually valid base64 (the last char leaves non-zero bits in a final partial byte). For instance, i1WsRn1uB1 should be i1WsRn1uBw (last char changes) to be a base64-encoding of 7 bytes. I suggest using four 22-char values for the four quantities (client secret, code, access token, refresh token) consistently throughout the spec. Here are four: 2YotnFZFEjr1zCsicMWpAA tGzv3JOkF0XG5Qx2TlKWIA 7Fjfp0ZBr1KtDRbnfVdmIw SplxlOBeZQQYbYS6WxSbIA -- James Manger
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
