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

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

+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
>
>