I agree that context does sufficiently differentiate. I guess I'm just lamenting the way that type has been overloaded in the base OAuth stuff and am already dreading the conversions that might go something like, "well which type of token type are we talking about here?"
This particular URN probably doesn't change that one way or the other and I'm okay with what you've proposed. I just felt compelled to mention the potential confusion point. On Tue, May 1, 2012 at 6:39 PM, Mike Jones <michael.jo...@microsoft.com> wrote: > I understand what you're saying, but I still believe that the URN is the > correct one. > > While I agree that the potential for confusion is unfortunate, context will > actually successfully differentiate the two uses of similar terms. Bear in > mind that the OAuth usage of the term is actually short for "Access Token > Type" (see OAuth Core sections 8.1 and 11.1), whereas the URN above is to > provide a type identifier for a particular kind of security token. > > I also believe that the examples in the Bearer spec (see > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-19#section-4), the MAC > spec (see > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01#section-5.1), and > the JWT spec will make the uses of these terms clear to implementers in > context. > > -- Mike > > -----Original Message----- > From: Brian Campbell [mailto:bcampb...@pingidentity.com] > Sent: Tuesday, May 01, 2012 4:26 PM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposed URN for JWT token type: > urn:ietf:params:oauth:token-type:jwt > > The only concern I might raise with it is that use of the "token-type" > part might lead to some confusion. The term token type and the parameter > token_type are already pretty loaded and have specific meaning from the core > OAuth framework: > http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-7.1 > > That token type is about providing "the client with the information required > to successfully utilize the access token to make a protected resource > request" (i.e. mac and bearer) and is not about the structure of the token > itself which is what this URI seems to want to describe. > JWTs are usually thought of as bearer type tokens but might someday have HoK > (http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120430/001860.html) > or mac like constructs. > > I don't think there's really a problem with name collisions here but I think > that the current use of token type in the frame work spec is already the > cause of some confusion and I'd hate to exacerbate that. > > On Tue, May 1, 2012 at 5:04 PM, Mike Jones <michael.jo...@microsoft.com> > wrote: >> I'm editing the JWT spec to prepare for the OAuth WG version and to >> track changes in the JOSE specs. Currently the "typ" values defined >> for JWT tokens are "JWT" and "http://openid.net/specs/jwt/1.0"; (see >> http://tools.ietf.org/html/draft-jones-json-web-token-08#section-5). >> I believe that the URN value should be changed to use a URN taken from >> the OAuth URN namespace urn:ietf:params:oauth (defined in >> http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-02). >> >> >> >> I propose to use the URN: >> >> urn:ietf:params:oauth:token-type:jwt >> >> >> >> I believe this fits well with the other four uses of this namespace to date: >> >> urn:ietf:params:oauth:grant-type:saml2-bearer >> >> >> urn:ietf:params:oauth:client-assertion-type:saml2-bearer >> >> urn:ietf:params:oauth:grant-type:jwt-bearer >> >> urn:ietf:params:oauth:client-assertion-type:jwt-bearer >> >> >> >> (The first two are from >> http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-11. The >> latter two are from >> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-04.) >> >> >> >> Do people agree with this URN choice? >> >> >> >> Thanks, >> >> -- Mike >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
