> 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