> If we're changing the bearer token's name, are we going to change the
> parameter name inside of MAC as well? At the moment, it's "id", which
> I've always found an odd naming choice.
>
> I would argue for consistency across the three main documents.
OAuth2 should be consistent with the authentication schemes for which it
dynamically issues credentials - not the other way around.
The root cause of the naming inconsistencies is that OAuth2 puts a massive
focus on "Access Token", instead of on "Dynamically-issued credentials".
An "access token response" is a dynamically-issued credential. First you need
to know the type of credential (token_type), then you need any extra values
specific to that type. [Plus you need metadata about the credentials
(expires_in, scope, how/where to renew/revoke, where to use!!).]
For the BEARER type you need: token.
For the MAC type you need: id, key, algorithm, issue time.
For the BASIC type you need: username, password.
For the TLS client cert type you need: certificate, private key.
...
The MAC spec defines mac_key and mac_algorithm fields, but uses the
access_token label instead of defining a mac_id field. It has to because OAuth2
treats access_token as a central concept, instead of a credential-specific
field.
I am sure developers would more easily understand (get a better mental model)
if an "access token responses" looked like the following examples:
{"type":"bearer", "token":"SlAV32hkKG", ...}
{"type":"mac", "id":"SlAV32hkKG", "key":"adijq39jdlaska9asud",
"algorithm":"hmac-sha-256", ...}
Is it worth clarifying?
Probably, for clarity in the long term.
But obviously there has been a huge amount invested in the current "access
token" focus. I am certainly not going to object to the much simpler fix of
renaming bearer_token to access_token.
--
James Manger
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
