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

[Dan Taflin <[e-mail]>]

+1

I agree with Andre and Stephen and others who argued against an MTI token type. As an architect of a (soon-to-be) oauth server I can state that we will almost certainly support bearer token only, and that we will be writing the code ourselves, not using a library. I don’t really see how a generic server-side library could be written anyway, since so much of what goes on at the server is left unspecified (what to put in the token and how to read it, for example). Maybe I just suffer from a lack of imagination.

Client-side libraries that deal with opaque tokens seem like a more realistic expectation, and specifying an MTI token type for a library to be able to declare itself “oauth 2.0 compliant” seems reasonable, though I’m not sure it’s important to mandate it.

Dan

On 12/2/11 2:13 PM, "André DeMarre" <[e-mail]> wrote:

+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]> <mailto:[e-mail]>
 To:  Stephen Farrell <[e-mail]> <mailto:[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]> <mailto:[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