-
assigned issue to
- changed status to open
Basic & other specs - token type
Basic states token type MUST be bearer. It has no check for that in the flow. It is implied in OAuth but could be unclear to some people.
The other issue is that we may be shooting ourselves in the foot with the MUST.
I think wording that Basic and implicit profile MUST implement Bearer and that the client MUST insure the token type in the response is one it supports. would be better.
For the server side the token type MUST be bearer unless some other token type has been negotiated with the client out of band.
That allows a future HoK token type extension without breaking the existing specs.
Comments (5)
-
-
reporter Re
#620- Update Sec 2.2.6.2. to allow for other token types, but make bearer mandatory to support for basic clients.→ <<cset 48e9fa9bfb73>>
-
reporter Re
#620- Update Sec 2.2.5.1 to allow for other token types, but make bearer mandatory to support for basic clients.→ <<cset 2867321e3a0e>>
-
reporter Re
#620- Update Sec 2.2.5.1 to allow for other token types, but make bearer mandatory to support for basic clients.→ <<cset 29bac7f6173d>>
-
reporter - changed status to resolved
Fixes
#620- Update Sec 2.1.2 & Sec 2.2.3 to allow for other token types, but make bearer mandatory to support for clients.→ <<cset ff9d2424d7c1>>
- Log in to comment
Saying that it must be Bearer is too restrictive. We need to allow another token type, such as holder-of-key, to be negotiated. The default will remain Bearer.