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]<mailto:[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]><mailto:[email protected]> To: Stephen Farrell <[email protected]><mailto:[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]><mailto:[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]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
