Re: [OAUTH-WG] Mandatory-to-implement token type
Stephen says: > On 12/02/2011 03:20 AM, Barry Leiba wrote: >> Maybe what would work best is some text that suggests what I say >> above: that toolkits intended for use in implementing OAuth services >> in general... implement [X and/or Y], and that code written for a >> specific environment implement what makes sense for that environment. >> It seems to me that to require any particular implementation in the >> latter case is arbitrary and counter-productive, and doesn't help >> anything interoperate. Whereas general-purpose toolkits that >> implement everything DO help interop. > > That'd work just fine for me. OK, so here's what I suggest... I propose adding a new section 7.2, thus: --- 7.2 Access Token Implementation Considerations Access token types have to be mutually understood among the authorization server, the resource server, and the client -- the access token issues the token, the resource server validates it, and the client is required to understand the type, as noted in section 7.1, above. Because of that, interoperability of program code developed separately depends upon the token types that are supported in the code. Toolkits that are intended for general use (for building other clients and/or servers), therefore, SHOULD implement as many token types as practical, to ensure that programs developed with those toolkits are able to use the token types they need. In particular, all general-use toolkits MUST implement bearer tokens [...ref...] and MAC tokens [...ref...]. Purpose-built code, built without such toolkits, has somewhat more flexibility, as its developers know the specific environment they're developing for. There's clearly little point to including code to support a particular token type when it's known in advance that the type in question will never be used in the intended deployment. Developers of purpose-built code are encouraged to consider future extensions and to plan ahead for changes in circumstances, and might still want to include support for multiple token types. That said, the choice of token-type support for such purpose-built code is left to the developers and their specific requirements. --- I think that expresses a reasonable compromise that might actually be followed and might actually do some good. Comments? Can we go with this and close this issue? (And, sorry, I've been a Bad Chair, and haven't put this in the tracker.) Barry ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
> Working group last call begins today on the threat model document: > http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01 > > Please review this version and post last call comments by 9 December. Here's a reminder that we have about a week left for the working group last call on this, and I haven't seen any comments since WGLC started. That's OK, if it's because there are no comments. If you have something to say, say it now, please. If the document really is ready to go, then that's great. Barry, chairing ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Mandatory-to-implement token type
I strongly object to a mandatory-to-implement clause for the MAC scheme. They are unnecessary and market forces have shown that implementers do not want or need this kind of an authentication scheme. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Barry Leiba Sent: Saturday, December 03, 2011 1:38 PM To: Stephen Farrell Cc: oauth WG Subject: Re: [OAUTH-WG] Mandatory-to-implement token type Stephen says: > On 12/02/2011 03:20 AM, Barry Leiba wrote: >> Maybe what would work best is some text that suggests what I say >> above: that toolkits intended for use in implementing OAuth services >> in general... implement [X and/or Y], and that code written for a >> specific environment implement what makes sense for that environment. >> It seems to me that to require any particular implementation in the >> latter case is arbitrary and counter-productive, and doesn't help >> anything interoperate. Whereas general-purpose toolkits that >> implement everything DO help interop. > > That'd work just fine for me. OK, so here's what I suggest... I propose adding a new section 7.2, thus: --- 7.2 Access Token Implementation Considerations Access token types have to be mutually understood among the authorization server, the resource server, and the client -- the access token issues the token, the resource server validates it, and the client is required to understand the type, as noted in section 7.1, above. Because of that, interoperability of program code developed separately depends upon the token types that are supported in the code. Toolkits that are intended for general use (for building other clients and/or servers), therefore, SHOULD implement as many token types as practical, to ensure that programs developed with those toolkits are able to use the token types they need. In particular, all general-use toolkits MUST implement bearer tokens [...ref...] and MAC tokens [...ref...]. Purpose-built code, built without such toolkits, has somewhat more flexibility, as its developers know the specific environment they're developing for. There's clearly little point to including code to support a particular token type when it's known in advance that the type in question will never be used in the intended deployment. Developers of purpose-built code are encouraged to consider future extensions and to plan ahead for changes in circumstances, and might still want to include support for multiple token types. That said, the choice of token-type support for such purpose-built code is left to the developers and their specific requirements. --- I think that expresses a reasonable compromise that might actually be followed and might actually do some good. Comments? Can we go with this and close this issue? (And, sorry, I've been a Bad Chair, and haven't put this in the tracker.) Barry ___ 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
Re: [OAUTH-WG] Mandatory-to-implement token type
I remain unconvinced that at this point MTI is going to be useful. I appreciate that some people want MAC, I could not support it being MTI. The below text with Bearer as MTI the only would be acceptable, if we need a MTI token handler. (I tend to think of token type, as bearer token type JWT/SAML etc, and this issue is more on the handling of classes of tokens) John Bradley On 2011-12-04, at 6:37 AM, Barry Leiba wrote: > Stephen says: >> On 12/02/2011 03:20 AM, Barry Leiba wrote: >>> Maybe what would work best is some text that suggests what I say >>> above: that toolkits intended for use in implementing OAuth services >>> in general... implement [X and/or Y], and that code written for a >>> specific environment implement what makes sense for that environment. >>> It seems to me that to require any particular implementation in the >>> latter case is arbitrary and counter-productive, and doesn't help >>> anything interoperate. Whereas general-purpose toolkits that >>> implement everything DO help interop. >> >> That'd work just fine for me. > > OK, so here's what I suggest... I propose adding a new section 7.2, thus: > > --- > 7.2 Access Token Implementation Considerations > > Access token types have to be mutually understood among the > authorization server, the resource server, and the client -- the > access token issues the token, the resource server validates it, and > the client is required to understand the type, as noted in section > 7.1, above. Because of that, interoperability of program code > developed separately depends upon the token types that are supported > in the code. > > Toolkits that are intended for general use (for building other clients > and/or servers), therefore, SHOULD implement as many token types as > practical, to ensure that programs developed with those toolkits are > able to use the token types they need. In particular, all general-use > toolkits MUST implement bearer tokens [...ref...] and MAC tokens > [...ref...]. > > Purpose-built code, built without such toolkits, has somewhat more > flexibility, as its developers know the specific environment they're > developing for. There's clearly little point to including code to > support a particular token type when it's known in advance that the > type in question will never be used in the intended deployment. > Developers of purpose-built code are encouraged to consider future > extensions and to plan ahead for changes in circumstances, and might > still want to include support for multiple token types. That said, > the choice of token-type support for such purpose-built code is left > to the developers and their specific requirements. > --- > > I think that expresses a reasonable compromise that might actually be > followed and might actually do some good. Comments? Can we go with > this and close this issue? (And, sorry, I've been a Bad Chair, and > haven't put this in the tracker.) > > Barry > ___ > 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
