> 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to