Exactly
11 dec 2011 kl. 18:27 skrev William Mills <wmi...@yahoo-inc.com>: > They are only compatible in the sense that they share the same security > characteristics. > > From: Leif Johansson <le...@mnt.se> > To: Paul Madsen <paul.mad...@gmail.com> > Cc: "oauth@ietf.org" <oauth@ietf.org> > Sent: Sunday, December 11, 2011 3:28 AM > Subject: Re: [OAUTH-WG] Mandatory-to-implement token type > > As an implementor of a toolkit let me offer this: the only use/requirement of > mac that I've seen is for backwards compat with 1.0a. > > > > 4 dec 2011 kl. 14:15 skrev Paul Madsen <paul.mad...@gmail.com>: > >> Commercial OAuth authorization servers are neither 'toolkits' nor 'purpose >> built code' - not used to build OAuth clients/servers but yet required to >> support more variety in deployments than a single purpose built server. >> >> But, that variety is driven by customer demand, and none of ours (yet?) have >> demanded MAC. If and when that demand comes, we will add support. >> >> To stipulate MAC as MTI would in no way reflect what the market wants. And >> 'interop' nobody wants is not meaningful interop. >> >> paul >> >> On 12/3/11 4:37 PM, 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 > > _______________________________________________ > 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
