Basic & other specs - token type

[John Bradley]

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.

[Michael Jones]

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.

[John Bradley]

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>>

[John Bradley]

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>>

[John Bradley]

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>>

[John Bradley]

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>>