The new draft will include a new token_type response parameter. In my original proposal I suggested making this an optional response parameter with a default value of 'bearer' or 'plain' to keep existing -10 implementation compliant with -11.
Options are: 1. Missing type response parameter means bearer token 2. Missing type response parameter means whatever the service default token type is 3. Servers must include an explicit token type with each response, where each token spec (bearer, signed, etc.) register their own type name 4. No token type. Type is determined by other attributes (such as secret and hash algorithm name). #1 and #3 are the most consistent with current design and best for interop. #1 requires no changes to -10 code, but leads to ugly spec organization (it links the bearer token spec with the framework spec). I'm strongly in favor of #3 as existing clients will ignore this and just assume bearer. Any server introducing a new token type will need to change clients anyway. Servers will need to be changed to add the new parameter but that's a trivial change (and -11 includes some normative changes already - all minor). So +1 on #3 for me. Please register your preference. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
