It buys us compromise. I agree with you 100% that "OAuth2 + Bearer" is an ideal compliance declaration; it promotes modular design as well. But I can also understand why some would be concerned about the core spec not adequately directing the efforts of implementers who want to write a general-purpose OAuth2 client or server library.
Regards, Andre DeMarre On Fri, Dec 2, 2011 at 2:23 PM, Richer, Justin P. <[email protected]> wrote: > I still don't see what the MTI requirement buys us in this relaxed case. > We're basically dictating what the best libraries would have. > > I still think "OAuth2 + Bearer" is a better compliance label than "OAuth2" > if you want real interoperability, and we should treat it as its own thing. > > -- Justin > > ------------------------------ > *From:* André DeMarre [[email protected]] > *Sent:* Friday, December 02, 2011 5:13 PM > *To:* OAuth WG > *Cc:* Richer, Justin P. > *Subject:* Re: [OAUTH-WG] Fwd: Re: Mandatory-to-implement token type > > +1 > > A server will issue whichever token types satisfy its own requirements, > so IMHO the idea of an MTI token type is a concern for client > implementations. We can distinguish between two categories of clients: (1) > interoperable clients and (2) service-specific clients. > > Obviously, service-specific clients must implement the token types used > by the authorization server. Interoperable clients (probably OAuth client > libraries) is where an MTI token type might have value. > > We can extend the differentiation of interoperable/service-specific to > authorization servers as well, where a generic OAuth server library is an > interoperable server, but it becomes a service-specific server when it is > used to implement an actual service. > > Is this a good compromise? If the spec defines interoperable and > service-specific clients and servers in such a way, then it can claim that > interoperable clients and servers must implement bearer tokens (for > example), but service-specific clients and servers have no MTI token type. > > Regards, > Andre DeMarre > > > On Fri, Dec 2, 2011 at 12:08 PM, Justin Richer <[email protected]> wrote: > >> Forwarding my response to the list. (oops) >> >> -- Justin >> >> -------- Original Message -------- Subject: Re: [OAUTH-WG] >> Mandatory-to-implement token type Date: Fri, 02 Dec 2011 15:07:39 -0500 >> From: >> Justin Richer <[email protected]> <[email protected]> To: Stephen >> Farrell <[email protected]> <[email protected]> >> >> I still don't think that having an MTI token type actually buys us >> anything, and what I *really* don't understand from this entire argument >> is the weight that's being put behind "Compliance with OAuth2" and what >> that means. >> >> With no MTI token type, we can still have interop for people who claim >> to be compliant with "OAuth2 + OAuth2 Bearer", or to borrow the example >> below, compliant with "OAuth2 + AWESOME". Both of these are compliant >> with "OAuth2" because they use OAuth2 to issue their tokens. *Those* >> parts of the library should work just fine to interop between each >> other. Since you're getting a JSON or fragment-encoded structure back as >> the token, you should be able to toss that into some kind of generic >> data structure and hand it to the token-handling part of your library, >> which is going to need more smarts to know what to do with it. >> >> A robust OAuth2 library, from server or client perspective, will likely >> do both Bearer and Mac and let you pick which you want. A good discovery >> system will aid that. An extended library will give you AWESOME tokens >> as well. *All* of these should be called compliant with OAuth2, in my >> opinion, and in this case it would be compliant with "OAuth2 + Bearer + >> MAC + AWESOME". A great library indeed! >> >> Making a MTI misses the point of the composability of the system, does >> absolutely nothing for real-world interop due to reasons I've already >> laid out in previous emails, will cause people to ignore the spec and be >> in noncompliance for something they think is dumb, have unused and >> untested code just to claim compliance that nobody cares about, and >> ultimately makes us look a bit silly for insisting that one solution >> will fit all use cases and that we can have any sense of real authority >> in this over developers. >> >> I'd like to point out that there's no MTI token-acquisition flow, which >> is arguably more important for worldwide interop and just as untenable a >> solution given the reality of the internet -- and I can also guarantee >> that we will never see agreement over an MTI grant type / token flow due >> to the simple fact that some instances will only do client credentials >> for 2-legged and some will do code for 3-legged, and the two of those >> probably don't want to talk to each other. >> >> In summary, I suggest that "compliance with OAuth2" be defined in terms >> of each of the separate composable documents and their combinations, and >> that "compliance with OAuth2" not be limited to a particular combination >> of any of them. >> >> -- Justin >> >> On 12/01/2011 09:27 PM, Stephen Farrell wrote: >> > >> > Hiya, >> > >> > On 12/02/2011 02:14 AM, Michael D Adams wrote: >> >> On Thu, Dec 1, 2011 at 5:44 PM, Stephen Farrell >> >> <[email protected]> <[email protected]> wrote: >> >>> On 12/02/2011 01:38 AM, Michael D Adams wrote: >> >>>> So an MTI token type + no client preference is equivalent to there >> >>>> only existing one token type. >> >>> >> >>> Maybe. >> >>> >> >>> However, no MTI token type + no client preference = no interop. >> >>> >> >>> So I don't get your argument. (When thinking of interop.) >> >> >> >> I think it's me that doesn't understand your argument. >> > >> > That can be mutual:-) >> > >> >> Suppose an authorization server implements OAuth2 and has some >> >> requirement that the MTI token type doesn't provide (as William Mills >> >> suggested), so the server implements token type AWESOME in addition to >> >> token type MTI. >> >> >> >> Whenever a token is requested, the authorization server issues one of >> >> type AWESOME. Type MTI is never issued. >> >> >> >> Why bother implementing type MTI if it's never used? >> > >> > That, I think, assumes that the requesting party only ever works with >> > the AWESOME token-type issuer. Seems a shame to me that whoever wrote >> > that code can't work with any other MTI token-type issuer as well, at >> > least. >> > >> >> Additionally, the authorization server could not implement type MTI >> >> but claim it did. There's no way for a third party to verify the >> >> claim since the authorization server never issues a token of type MTI. >> > >> > Irrelevant. I could claim to be handsome. Would work equally >> > well. >> > >> >> If tokens of type MTI are never used by this server, how does the MTI >> >> token type help interop?Is your argument that this server would say >> >> "No, we do not support OAuth2. We do, however, support >> >> OAuth2+AWESOME."? That semantic argument I understand, but I am >> >> ignorant as to how/if it fits into the RFC. >> > >> > No, my argument is that there are many servers and many clients on >> > the Internet and having them all have a way to interop, if they >> > choose to do so, is a good thing in itself. Writing an RFC so that >> > its a random pick as to whether they do or don't interop is not IMO >> > a good thing. >> > >> > S. >> > >> > >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
