Brian Campbell
2016-06-20 19:45:23 UTC
Another open issue in Token Exchange is the question of should there be a
way to use short names for some common token type identifiers?
URIs are necessary in the general case for extensibility and
vendor/deployment specific types. But short names like access_token and jwt
are aesthetically appealing and slightly more efficient in terms of bytes
on the wire and url-encoding.
There seemed to be rough consensus in Prague ('No objection to use the
proposed mechanism for a default prefix' from
https://www.ietf.org/proceedings/93/minutes/minutes-93-oauth) for
supporting a shorthand for commonly used types - i.e. when the value does
not contain a ":" character, the value would be treated as though
urn:ietf:params:oauth:token-type: were prepended to it. So, for example,
the value jwt for requested_token_type would be semantically equivalent to
urn:ietf:params:oauth:token-type:jwt and the value access_token would be
equivalent to urn:ietf:params:oauth:token-type:access_token.
However, it was a fairly brief discussion during a long meeting in Prague
with rather fatigued participants. And it has since been suggested that
making protocol participants handle both syntaxes will unnecessarily
complicate the supporting code. With that suggestion the text that allowed
for the short names was pulled out of a pre-published draft of the draft.
So the WG draft currently only supports the use of full URIs as the *_type
values.
I'd like to close out this issue sometime soon. So please speak now, if you
have a preference. I was personally in favor of allowing for the shorthand
but don't feel all that strongly about it. So unless there's some support
expressed on this list for allowing the shorthand, I'm inclined to leave
the core text of the draft as it is thus using only full URI values and
remove the open issue about it in the next revision.
way to use short names for some common token type identifiers?
URIs are necessary in the general case for extensibility and
vendor/deployment specific types. But short names like access_token and jwt
are aesthetically appealing and slightly more efficient in terms of bytes
on the wire and url-encoding.
There seemed to be rough consensus in Prague ('No objection to use the
proposed mechanism for a default prefix' from
https://www.ietf.org/proceedings/93/minutes/minutes-93-oauth) for
supporting a shorthand for commonly used types - i.e. when the value does
not contain a ":" character, the value would be treated as though
urn:ietf:params:oauth:token-type: were prepended to it. So, for example,
the value jwt for requested_token_type would be semantically equivalent to
urn:ietf:params:oauth:token-type:jwt and the value access_token would be
equivalent to urn:ietf:params:oauth:token-type:access_token.
However, it was a fairly brief discussion during a long meeting in Prague
with rather fatigued participants. And it has since been suggested that
making protocol participants handle both syntaxes will unnecessarily
complicate the supporting code. With that suggestion the text that allowed
for the short names was pulled out of a pre-published draft of the draft.
So the WG draft currently only supports the use of full URIs as the *_type
values.
I'd like to close out this issue sometime soon. So please speak now, if you
have a preference. I was personally in favor of allowing for the shorthand
but don't feel all that strongly about it. So unless there's some support
expressed on this list for allowing the shorthand, I'm inclined to leave
the core text of the draft as it is thus using only full URI values and
remove the open issue about it in the next revision.