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]>
To: Stephen Farrell <[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]> 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
