Re: [OAUTH-WG] Fwd: Re: Mandatory-to-implement token type

[André DeMarre <[e-mail]>]

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