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

From: Stephen Farrell <[email-masked]>
Date: Thu, 01 Dec 2011 21:25:44 +0000

Barry, all,

First, apologies for being so slow responding, various
travels got in the way. I hope we can quickly resolve this now.

Bit of process first: at the meeting we discussed this and at the
end of that discussion, there were quite a few more folks for the
"pick one" position. People who favour that outcome and really
care about that need to speak up on the list, since the list
consensus trumps the sense of the room in the chairs' evaluation
of the WG consensus.

Second, at the meeting I said that I'd like to see either MAC or
bearer picked as MTI, and if not, that I want the draft to say
why its ok to have no MTI token type. So the WG either need to
pick one, or else explicitly and convincingly justify not
picking one. That's the "firm" AD position to which Barry
referred. (I didn't properly call out the "if not" part of
that in my AD review, sorry.)

My own argument for picking one is simple: if every relevant
piece of code has to know how to handle one then it becomes
easier to get interop. If everyone decides for themselves
then interop is less likely since there are currently two
choices and may be more in future.

I do realise that the background here and current practice
is that code tends to be written that is specific to a
resource server (or however that's best phrased) but that's
maybe where the IETF differs from the community that produced
OAuth - here we want two independent implementers who've
never talked to produce code that interops even so.

I also realise that that's not the full story for getting
interop with OAuth and that more is needed. However, this
aspect is otherwise fully specified and so I don't buy the
argument that this isn't worth doing just because we don't
have the full registration story etc. figured out. If we don't
sort this out now, then later specs will have to update
this one in this respect. possibly making existing code
"non-compliant" in some sense, so just going ahead and doing
it right now is better.

So, pick one (my strong personal preference) or establish and
document why you're not picking one seem to me to be the choices
available.

Regards,
Stephen.

On 11/17/2011 08:28 AM, Barry Leiba wrote:
> Stephen, as AD, brought up the question of mandatory-to-implement
> token types, in the IETF 82 meeting.  There was some extended
> discussion on the point:
>
> - Stephen is firm in his belief that it's necessary for
> interoperability.  He notes that mandatory to *implement* is not the
> same as mandatory to *use*.
> - Several participants believe that without a mechanism for requesting
> or negotiating a token type, there is no value in having any type be
> mandatory to implement.
>
> Stephen is happy to continue the discussion on the list, and make his
> point clear.  In any case, there was clear consensus in the room that
> we *should* specify a mandatory-to-implement type, and that that type
> be bearer tokens.  This would be specified in the base document, and
> would make a normative reference from the base doc to the bearer token
> doc.
>
> We need to confirm that consensus on the mailing list, so this starts
> the discussion.  Let's work on resolving this over the next week or
> so, and moving forward:
>
> 1. Should we specify some token type as mandatory to implement?  Why
> or why not (*briefly*)?
>
> 2. If we do specify one, which token type should it be?
>
> Barry, as chair
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: William Mills <[email-masked]>
Date: Thu, 1 Dec 2011 15:37:04 -0800 (PST)

Re: "So, pick one (my strong personal preference) or establish and
document why you're not picking one seem to me to be the choices
available."

We don't have discovery done (enough) yet to lean on it in the core spec, but if we did I'd be in favor of something that says that you must implement either an MTI token OR a discovery mechanism that advertises at least one token.  Would that be workable?  

We could bang on the discovery stuff in pretty short order I think if we needed to.

-bill

________________________________
 From: Stephen Farrell <[email-masked]>
To: Barry Leiba <[email-masked]> 
Cc: oauth WG <[email-masked]> 
Sent: Thursday, December 1, 2011 1:25 PM
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type

Barry, all,

Regards,
Stephen.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 1 Dec 2011 16:23:38 -0800

Because different token types have distinct advantages in different scenarios, choosing a single MTI would be difficult. E.g. MAC tokens work well for non-TLS protected resources.  Bearer tokens in contrast are easier to use, but require TLS protected service to avoid theft-of-credential. Even at this level, site security policies will simply override whatever is stated in the specification and choose one type only. 

Having multiple MTIs, suggests choice and that causes other problems. What happens when a client wants to use a bearer token over an unprotected connection? How does the client discover what can be used and when?

The approach we have now where the Token specification defines interop requirements and a profile for use with OAuth2 seems to be a good way to go.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 02 Dec 2011 01:19:32 +0000

> We don't have discovery done (enough) yet to lean on it in the core spec, but if we did I'd be in favor of something that says that you must implement either an MTI token OR a discovery mechanism t…

Might be, but I think the "if we did" says timing is against that
argument.

> We could bang on the discovery stuff in pretty short order I think if we needed to.

Really? Doesn't the WG first need to recharter? We're talking about
how to get the base spec to be an RFC right now, which is a shorter
term thing IMO.

S.

>   From: Stephen Farrell<[email-masked]>
> To: Barry Leiba<[email-masked]>
> Cc: oauth WG<[email-masked]>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 02 Dec 2011 01:23:26 +0000

On 12/02/2011 12:23 AM, Phil Hunt wrote:
> Because different token types have distinct advantages in different scenarios, choosing a single MTI would be difficult.

I just don't get that. Why is it somehow difficult to pick one
but at the same time easy to implement any?

> E.g. MAC tokens work well for non-TLS protected resources.  Bearer tokens in contrast are easier to use, but require TLS protected service to avoid theft-of-credential.

So picking is a nuisance sure. But it helps interop.

 > Even at this level, site security policies will simply override 
whatever is stated in the specification and choose one type only.

Yes, but those policies will be affected by what's available in
the running code. I'd like if what's available was known when
the coder says "we implement RFC <foo>"

> Having multiple MTIs, suggests choice and that causes other problems. What happens when a client wants to use a bearer token over an unprotected connection? How does the client discover what can be…

Having no MTI causes identical problems.

> The approach we have now where the Token specification defines interop requirements and a profile for use with OAuth2 seems to be a good way to go.

We disagree about that I guess. To me it seems a peculiar way to go
unless one assumes that coders write code that's specific to a specific
service provider.

S.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 01 Dec 2011 17:35:39 -0800

> So picking is a nuisance sure. But it helps interop.

This smacks of truth by blatant assertion. If something is required to
be implemented but is unused -- which will happen if the profile
chosen by the SDK doesn't need the required one -- you're not going
to get better interoperability, you're just going to get untested code.

I don't see what the big deal is about saying that discovery, etc, is
for a -bis release of this PS. That would take care of your problem of
reaching back into this PS to change just this part. And what are the
chances of not having a recycle anyway with any well-deployed PS?
Zero?

  |We disagree about that I guess. To me it seems a peculiar way to go
  |unless one assumes that coders write code that's specific to a specific
  |service provider.

But that is exactly what's happening in the field.

Mike

Mike

---

From: Michael D Adams <[email-masked]>
Date: Thu, 1 Dec 2011 17:38:46 -0800

I echo Justin Richer's comments.

> 1. Should we specify some token type as mandatory to implement?  Why

No.  There's no mechanism in the spec for clients to request a
particular token type, so there's no opportunity for the authorization
server to decide what token type to send.  The only thing the
authorization server can do is pick its own preference.

If there's an MTI token type, and with the absence of a client
preference, the authorization server will have to pick the MTI token
type.

So an MTI token type + no client preference is equivalent to there
only existing one token type.

Mike

PS: I sent this 2011/11/17 but apparently hit reply instead of reply all.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 02 Dec 2011 01:44:02 +0000

Hiya,

On 12/02/2011 01:38 AM, Michael D Adams wrote:
> On Thu, Nov 17, 2011 at 12:28 AM, Barry Leiba<[email-masked]>  wrote:

Maybe.

However, no MTI token type + no client preference = no interop.

So I don't get your argument. (When thinking of interop.)

S.

---

From: William Mills <[email-masked]>
Date: Thu, 1 Dec 2011 17:50:33 -0800 (PST)

If we MTI a "weaker" token type (arguably Bearer falls here) that means 
the spec will be inappropriate in higher security requirement situations, those folks walk away.

If we MTI something like SAML it makes the folks that want a light weight Bearer token solution walk away.

________________________________
 From: Stephen Farrell <[email-masked]>
To: Phil Hunt <[email-masked]> 
Cc: Barry Leiba <[email-masked]>; oauth WG <[email-masked]> 
Sent: Thursday, December 1, 2011 5:23 PM
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type

<snip /

________________________________
 From: Stephen Farrell <[email-masked]>
To: Phil Hunt <[email-masked]> 
Cc: Barry Leiba <[email-masked]>; oauth WG <[email-masked]> 
Sent: Thursday, December 1, 2011 5:23 PM
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type

S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 02 Dec 2011 01:53:29 +0000

> the spec will be inappropriate in higher security requirement situations, those folks walk away.

Disagree. People who need more can specify more.

The base spec not having an MTI doesn't help them at all since
absent any MTI it'd clearly not be appropriate for higher
security environments to use your term.

> If we MTI something like SAML it makes the folks that want a light weight Bearer token solution walk away.

I would agree that SAML might be too heavy. If the WG do
pick an MTI then it does need to be relatively simple.

S.

> To: Phil Hunt<[email-masked]>
> Cc: Barry Leiba<[email-masked]>; oauth WG<[email-masked]>
> To: Phil Hunt<[email-masked]>
> Cc: Barry Leiba<[email-masked]>; oauth WG<[email-masked]>
> the coder says "we implement RFC<foo>"
>

---

From: Michael D Adams <[email-masked]>
Date: Thu, 1 Dec 2011 18:14:10 -0800

> So I don't get your argument. (When thinking of interop.)

I think it's me that doesn't understand your argument.

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?

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.

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.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 02 Dec 2011 02:22:13 +0000

Hi Mike,

On 12/02/2011 01:35 AM, Michael Thomas wrote:
>>> E.g. MAC tokens work well for non-TLS protected resources. Bearer
>>> tokens in contrast are easier to use, but require TLS protected
>>> service to avoid theft-of-credential.
>>
> This smacks of truth by blatant assertion.

Of course. My 2 sentences have 10 words. Yours has 7. Neither can
really capture everything.

Nonetheless, picking between one of two things does help interop
IMO.

 > If something is required to

That'd be a fair point if the MTI wasn't used.

While that might be true of MAC, I doubt it'd be true for bearer,
which is what seemed to be the thing folks in the room in Taipei
would pick, had they to pick.

So yes, your argument would be telling if the WG chose a rare
beast as the MTI thing.

> chances of not having a recycle anyway with any well-deployed PS?

That's not a reason to not fix an easily fixable thing now though.

> But that is exactly what's happening in the field.

To date yes. I would (perhaps naively) hope for that to get better
(by at least a bit) when we have an OAuth 2.0 RFC.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 02 Dec 2011 02:27:49 +0000

Hiya,

> I think it's me that doesn't understand your argument.

That can be mutual:-)

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

> claim since the authorization server never issues a token of type MTI.

Irrelevant. I could claim to be handsome. Would work equally
well.

> token type help interop?Is your argument that this server would say

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.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 01 Dec 2011 18:57:35 -0800

> That's not a reason to not fix an easily fixable thing now though.

What bothers me here is overreach. If the wg has come to the conclusion
that the standardizing the status quo of purpose built sdk's is a Good Thing,
then that is still a pretty good reason to create a standard -- if nothing else,
it dissuades people from badly rolling their own.  Stopping there is ok, IMO.
It still serves a purpose.

Also: it seems to me that the longer term solution for libraries implementing
oauth is not to have a single point of interoperability, but a suite of algorithms/
methods that satisfy the various policies of many/most deployments. That
is, they're going to need to MUST IMPLEMENT a whole lot of things, not just one.

So I just don't see this MUST as doing anything especially useful, and has the
downside of making perfectly reasonable purpose-build SDK's "non-conformant".
That said, I don't think the world will fail to revolve if this goes in there. Mostly,
I think that it will be ignored. But that's what bothers me: putting stuff in that
you know will be disregarded with impunity is not good.

Mike, listening to Ken Burns' Prohibition in the background

---

From: Michael D Adams <[email-masked]>
Date: Thu, 1 Dec 2011 18:57:51 -0800

> that code can't work with any other MTI token-type issuer as well, at

Sorry, I was unclear.  Suppose awesome.com only issues token of type
AWESOME and mti.com only issues tokens of type MTI.  Suppose further
that client X understands how to handle both types of tokens and can
receive and use tokens from both awesome.com and mti.com.

My question does not concern the client.  My question is: Why should
awesome.com bother implementing type MTI if it will never issue such a
token?

> Irrelevant. I could claim to be handsome. Would work equally

I claim the argument helps show the meaninglessness of defining an MTI
token type, but I think my statement of it is poorly formulated and
trying to restate it more clearly will just take us down a road with
as much relevance to the discussion as you grant my initial statement
:)  So I concede.

> its a random pick as to whether they do or don't interop is not IMO

Thanks.  I understand better what you're saying.  I believe you're saying:

1. In a world where there is a MTI token type, my hypothetical
only-issue-tokens-of-type-AWESOME has explicitly opted out of
interoperability.
2. In a world where there is no MTI token type, interoperability
becomes ad hoc and so non-existant.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 1 Dec 2011 22:20:22 -0500

> However, no MTI token type + no client preference = no interop.

I think this exchange, coupled with what you Stephen said in Taipei
(noting that "mandatory to implement" doesn't mean "mandatory to
use"), points out a basic difference between how Stephen is thinking
about this and how at least some of the WG participants are.  Let me
see if calling this out helps:

Stephen is thinking that code will be reused.  Perhaps there'll be a
limited number of coded toolkits, and their code will be used to
implement various authorization servers, etc.  That's the way a lot of
Internet code is done today.  In that case, Stephen posits, if we tell
the toolkit writers that they MUST implement X, then at least when X
is being used, implementations based on the different toolkits can
always interoperate.  Lacking that directive, a toolkit that only
implements X will be unable to interoperate with a toolkit that only
implements Y.

Others are thinking that deployed code will be specific to a
particular environment, and it doesn't help at all for that code to
support X if the environment demands Y.  There's no interop benefit
from the "MUST implement X" directive if the code has been written
specifically for that environment, and, as Mike T says, it only
results in untested code and wasted development time.

I see both sides of this, but in the end I think what Mike says is
spot on, here.  I think it would be very nice to strongly encourage
toolkit writers to support all the available options, but there's
absolutely no reason to require, and no benefit in requiring,
purpose-built code to do anything of the sort.

Maybe what would work best is some text that suggests what I say
above: that toolkits intended for use in implementing OAuth services
in general... implement [X and/or Y], and that code written for a
specific environment implement what makes sense for that environment.
It seems to me that to require any particular implementation in the
latter case is arbitrary and counter-productive, and doesn't help
anything interoperate.  Whereas general-purpose toolkits that
implement everything DO help interop.

Barry, as participant

---

From: William Mills <[email-masked]>
Date: Thu, 1 Dec 2011 20:58:55 -0800 (PST)

The problem is that token type AWESOME may have different mechanics for submission.  The client has to know how to use it.  I do agree we have a disconnect here, and that what we have right now leans completely on "reading the service documentation" for the Auth and RP endpoints you want to use.

________________________________
 From: Michael D Adams <[email-masked]>
To: Stephen Farrell <[email-masked]> 
Cc: Barry Leiba <[email-masked]>; oauth WG <[email-masked]> 
Sent: Thursday, December 1, 2011 6:14 PM
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 02 Dec 2011 08:59:48 +0000

Hi Barry,

On 12/02/2011 03:20 AM, Barry Leiba wrote:
> implement everything DO help interop.j

That'd work just fine for me.

> Barry, as participant

Stephen, as breakfast eater:-)

---

From: "Bart Wiegmans" <[email-masked]>
Date: Fri, 2 Dec 2011 10:02:20 +0100

Just chipping in: I'd think [X and/or Y] should be Bearer and MAC,
respectively. Between them I think they can cover a lot of use cases.
Regards, Bart

-----Oorspronkelijk bericht-----
Van: [email-masked] [mailto:[email-masked]] Namens
Stephen Farrell
Verzonden: vrijdag 2 december 2011 10:00
Aan: Barry Leiba
CC: oauth WG
Onderwerp: Re: [OAUTH-WG] Mandatory-to-implement token type

Hi Barry,

---

From: Blaine Cook <[email-masked]>
Date: Fri, 2 Dec 2011 13:09:48 +0000

> implements X will be unable to interoperate with a toolkit that only

My $0.02 (tl;dr: I agree with Barry):

Libraries are the point of code re-use for OAuth at the moment. If two
libraries (e.g., "Ruby OAuth" and "Java OAuth") implement all the
necessary bits of OAuth, then people using those libraries can expect
(or hope for) interop. We cannot force compliance, but we can mandate
it.

If a service provider chooses to allow only a subset of OAuth's
functionality, and a general-purpose tool (i.e., NOT a library, though
perhaps written using a library) doesn't support that subset, then
obviously the implementations are not interoperable. However, more
likely than not, tools are designed to be used against specific
service providers OR other standards (which would in either case
mandate the way(s) in which to use OAuth).

SO, having Mandatory to Implement schemes in the general sense is pointless.
BUT, having BOTH Bearer and MAC be Mandatory to Implement for
general-purpose libraries IS useful, and will help interop (assuming
library authors bother to follow the spec).

b.

---

From: Barry Leiba <[email-masked]>
Date: Sat, 3 Dec 2011 16:37:40 -0500

> That'd work just fine for me.

OK, so here's what I suggest... I propose adding a new section 7.2, thus:

-----------------------------------
7.2 Access Token Implementation Considerations

Access token types have to be mutually understood among the
authorization server, the resource server, and the client -- the
access token issues the token, the resource server validates it, and
the client is required to understand the type, as noted in section
7.1, above.  Because of that, interoperability of program code
developed separately depends upon the token types that are supported
in the code.

Toolkits that are intended for general use (for building other clients
and/or servers), therefore, SHOULD implement as many token types as
practical, to ensure that programs developed with those toolkits are
able to use the token types they need.  In particular, all general-use
toolkits MUST implement bearer tokens [...ref...] and MAC tokens
[...ref...].

Purpose-built code, built without such toolkits, has somewhat more
flexibility, as its developers know the specific environment they're
developing for.  There's clearly little point to including code to
support a particular token type when it's known in advance that the
type in question will never be used in the intended deployment.
Developers of purpose-built code are encouraged to consider future
extensions and to plan ahead for changes in circumstances, and might
still want to include support for multiple token types.  That said,
the choice of token-type support for such purpose-built code is left
to the developers and their specific requirements.
-----------------------------------

I think that expresses a reasonable compromise that might actually be
followed and might actually do some good.  Comments?  Can we go with
this and close this issue?  (And, sorry, I've been a Bad Chair, and
haven't put this in the tracker.)

Barry

---

From: Mike Jones <[email-masked]>
Date: Sun, 4 Dec 2011 02:26:07 +0000

I strongly object to a mandatory-to-implement clause for the MAC scheme.  They are unnecessary and market forces have shown that implementers do not want or need this kind of an authentication scheme.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Saturday, December 03, 2011 1:38 PM
To: Stephen Farrell
Cc: oauth WG
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type

Access token types have to be mutually understood among the authorization server, the resource server, and the client -- the access token issues the token, the resource server validates it, and the client is required to understand the type, as noted in section 7.1, above.  Because of that, interoperability of program code developed separately depends upon the token types that are supported in the code.

Toolkits that are intended for general use (for building other clients and/or servers), therefore, SHOULD implement as many token types as practical, to ensure that programs developed with those toolkits are able to use the token types they need.  In particular, all general-use toolkits MUST implement bearer tokens [...ref...] and MAC tokens [...ref...].

Purpose-built code, built without such toolkits, has somewhat more flexibility, as its developers know the specific environment they're developing for.  There's clearly little point to including code to support a particular token type when it's known in advance that the type in question will never be used in the intended deployment.
Developers of purpose-built code are encouraged to consider future extensions and to plan ahead for changes in circumstances, and might still want to include support for multiple token types.  That said, the choice of token-type support for such purpose-built code is left to the developers and their specific requirements.
-----------------------------------

I think that expresses a reasonable compromise that might actually be followed and might actually do some good.  Comments?  Can we go with this and close this issue?  (And, sorry, I've been a Bad Chair, and haven't put this in the tracker.)

Barry

---

From: John Bradley <[email-masked]>
Date: Sun, 4 Dec 2011 14:39:45 +0900

I remain unconvinced that at this point MTI is going to be useful.  

I appreciate that some people want MAC, I could not support it being MTI.

The below text with Bearer as MTI the only would be acceptable, if we need a MTI token handler.
(I tend to think of token type, as bearer token type JWT/SAML etc,  and this issue is more on the handling of classes of tokens)

John Bradley

---

From: Anthony Nadalin <[email-masked]>
Date: Sun, 4 Dec 2011 09:36:46 +0000

I agree we have no plans to implement MAC if we wanted that we would have been happy with OAUTH 1.0a but that was not deployable

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Saturday, December 03, 2011 6:26 PM
To: Barry Leiba; Stephen Farrell
Cc: oauth WG
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Saturday, December 03, 2011 1:38 PM
To: Stephen Farrell
Cc: oauth WG
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type

Barry

---

From: Paul Madsen <[email-masked]>
Date: Sun, 04 Dec 2011 08:15:26 -0500

Commercial OAuth authorization servers are neither 'toolkits' nor 
'purpose built code' - not used to build OAuth clients/servers but yet 
required to support more variety in deployments than a single purpose 
built server.

But, that variety is driven by customer demand, and none of ours (yet?) 
have demanded MAC. If and when that demand comes, we will add support.

To stipulate MAC as MTI would in no way reflect what the market wants. 
And 'interop' nobody wants is not meaningful interop.

paul

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 04 Dec 2011 14:20:25 +0000

FWIW, if Barry's suggested text was amended to say "MUST do bearer,
MAY do mac" I'd still be ok with that.

Much as I'd like if the mac scheme were more popular, my comment
on -22 was interop and not really security related.

S

---

From: Mike Jones <[email-masked]>
Date: Sun, 4 Dec 2011 14:21:24 +0000

The core spec should be completely silent on MAC, as it is not ready for prime time.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Sunday, December 04, 2011 6:20 AM
To: Paul Madsen
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type

FWIW, if Barry's suggested text was amended to say "MUST do bearer, MAY do mac" I'd still be ok with that.

Much as I'd like if the mac scheme were more popular, my comment on -22 was interop and not really security related.

S

On 12/04/2011 01:15 PM, Paul Madsen wrote:
> But, that variety is driven by customer demand, and none of ours 
> (yet?) have demanded MAC. If and when that demand comes, we will add support.
>
>>>> above: that toolkits intended for use in implementing OAuth 
>>>> services in general... implement [X and/or Y], and that code 
>>>> written for a specific environment implement what makes sense for that environment.
>> Toolkits that are intended for general use (for building other 
>> clients and/or servers), therefore, SHOULD implement as many token 
>> types as practical, to ensure that programs developed with those 
>> toolkits are able to use the token types they need. In particular, 
>> all general-use toolkits MUST implement bearer tokens [...ref...] and 
>> MAC tokens [...ref...].
>>

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 04 Dec 2011 14:44:12 +0000

Whatever. If the entire WG want to get excited by the difference between
MAY do mac and not mentioning it then fine.

Personally, I'd be more interested in getting done rather than nailing
that final nail into any coffin;-)

S

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 4 Dec 2011 11:30:56 -0700

Bearer tokens are practically identical to OAuth 1.0 PLAINTEXT. Get your facts right.

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Anthony Nadalin
> Sent: Sunday, December 04, 2011 1:37 AM
> To: Mike Jones; Barry Leiba; Stephen Farrell
> Cc: oauth WG
> I agree we have no plans to implement MAC if we wanted that we would
> have been happy with OAUTH 1.0a but that was not deployable
> 
> I strongly object to a mandatory-to-implement clause for the MAC scheme.
> They are unnecessary and market forces have shown that implementers do
> not want or need this kind of an authentication scheme.
> 
> 				-- Mike
> 
> Access token types have to be mutually understood among the authorization
> server, the resource server, and the client -- the access token issues the
> token, the resource server validates it, and the client is required to
> understand the type, as noted in section 7.1, above.  Because of that,
> interoperability of program code developed separately depends upon the
> token types that are supported in the code.
> 
> Toolkits that are intended for general use (for building other clients and/or
> servers), therefore, SHOULD implement as many token types as practical, to
> ensure that programs developed with those toolkits are able to use the
> token types they need.  In particular, all general-use toolkits MUST
> implement bearer tokens [...ref...] and MAC tokens [...ref...].
> 
> developing for.  There's clearly little point to including code to support a
> particular token type when it's known in advance that the type in question
> will never be used in the intended deployment.
> extensions and to plan ahead for changes in circumstances, and might still
> want to include support for multiple token types.  That said, the choice of
> token-type support for such purpose-built code is left to the developers and
> their specific requirements.
> followed and might actually do some good.  Comments?  Can we go with this
> and close this issue?  (And, sorry, I've been a Bad Chair, and haven't put this
> in the tracker.)
> 
> Barry

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 4 Dec 2011 11:51:58 -0700

This has been going on for far too long.

There is a well-established gap between the two tokens and those who support them and we are NEVER going to reach consensus. Instead we have a war of attrition were each side is just keeping at it hoping the other side will give up. The only compromise we were able to reach in 2 years is to keep the v2 specification token agnostic. If we are now going to violate that for the perceived notion of interoperability, we should at least do it with due process.

Stephen - In previous discussion, my understanding was that you were opposed to publishing OAuth 2.0 without MAC because that would make 2.0 a less secure option than 1.0. While, as you stated, this thread is not about security but about interoperability, the two are at odds here and you can only have one. If the specification picked a winner by making only one required, and if that one is Bearer, I see no point whatsoever in spending any more of my time on MAC. It would be DOA.

The WG is clearly opposed to making MAC required, but that is not the only question to ask. The question for the group is also, do you even want MAC? Are you planning on using it? And will you use it alongside Bearer or exclusively?

If there is sufficient WG support for MAC, making Bearer required alone violates that spirit because it will make MAC another specification no one cares about and we don't need more of those. If there is no sufficient support, let's just drop it as a WG item and let it resurface later if at all.

As for the "market has decided" argument - I only want to warn those who use it that it is a double-edge-sword. The same people who now use that argument are also the members of this group responsible for some of the new astronaut architecture features proposed in the rechartering discussion. If you intend to make this your winning argument, the WG must then apply the same rational to your other proposals.

EHL

> Of Stephen Farrell
> Sent: Sunday, December 04, 2011 6:44 AM
> To: Mike Jones
> Cc: [email-masked]
> Personally, I'd be more interested in getting done rather than nailing that
> final nail into any coffin;-)
> 
> S
> 
> > Of Stephen Farrell
> > Much as I'd like if the mac scheme were more popular, my comment on -22
> was interop and not really security related.
> >
> > S
> >
> >> 'purpose built code' - not used to build OAuth clients/servers but
> >> yet required to support more variety in deployments than a single
> >> purpose built server.
> >>
> >>>>> It seems to me that to require any particular implementation in
> >>>>> the latter case is arbitrary and counter-productive, and doesn't
> >>>>> help anything interoperate. Whereas general-purpose toolkits that
> >>> all general-use toolkits MUST implement bearer tokens [...ref...]
> >>> and MAC tokens [...ref...].
> >>>
> >>> I think that expresses a reasonable compromise that might actually
> >>> be followed and might actually do some good. Comments? Can we go
> >>> with this and close this issue? (And, sorry, I've been a Bad Chair,
> >>> and haven't put this in the tracker.)
> >>>
> >>> Barry

---

From: Blaine Cook <[email-masked]>
Date: Sun, 4 Dec 2011 23:34:16 +0000

> I strongly object to a mandatory-to-implement clause for the MAC scheme.  They are unnecessary and market forces have shown that implementers do not want or need this kind of an authentication sche…

I'd say that Twitter, Flickr, Dropbox and dozens of other sites that
have shipped OAuth 1.0a (MAC) in production and for billions of
requests per day is a pretty strong market force.

People (especially politically incentivised standards wonks) arguing
on a mailing list isn't a strong market force, and there are far fewer
successful APIs that use Bearer tokens. Which isn't to say that they
won't, just to say that what you want and what's used in the wild are
very different things. Or, citation needed.

b.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 05 Dec 2011 00:00:16 +0000

Hiya,

> Stephen - In previous discussion, my understanding was that you were opposed to publishing OAuth 2.0 without MAC because that would make 2.0 a less secure option than 1.0. While, as you stated, thi…

I do dislike the idea of not having a "better" scheme than
bearer. I don't have so much of an issue about its 2119
status (MUST vs. MAY) so long as its well defined (having
said that I'd presonally prefer MUST). I guess you and I
disagree about the significance of that "status" issue.

But as you say though that's a different issue from the
one currently under discussion so I'd rather keep things
separate and move along. (That is, if someone wants to
chat about desirable security levels please change at
least the subject line.)

> As for the "market has decided" argument - I only want to warn those who use it that it is a double-edge-sword. The same people who now use that argument are also the members of this group responsi…

Well, I wouldn't be quite so black-and-white about it,
but its a fair comment to say that arguing against mac but
for use of oauth for higher security environments could raise
some questions. I've not tracked if someone's actually making
just that argument however, so I guess this won't come up
until a) we've got the base spec out and b) the WG have proposed
some new charter. If a proposed new charter assumes something
the work-to-date has not delivered then something will have
to give, so I'd encourage the WG to consider that as they
discuss re-chartering. I'm confident however that the WG chairs
would spot that and help try to direct the WG towards something
self-consistent. Again though, that's also not the current issue
under discussion, and in that case, I guess there is (or was,
seems quiet now) a re-chartering thread that seems appropriate
for that topic.

Cheers,
S.

---

From: Justin Richer <[email-masked]>
Date: Mon, 5 Dec 2011 09:46:29 -0500

I agree that the core should remain token agnostic. However, I do see 
value in MAC. The ability to have parameter values signed by a client 
key is important for security in depth, even in a world of pervasive 
server-side TLS. I would like to see MAC tokens mature to the point 
where we could use it in all of our current OAuth 1.0 use cases, but 
that's another thread that I haven't been able to give appropriate 
attention to.

I still think that the MTI language (even the cleaner one that Barry 
proposed here) is a red herring and doesn't buy us much in reality.

  -- Justin

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 5 Dec 2011 10:47:46 -0800

+1, what John said.

Marius

---

From: Leif Johansson <[email-masked]>
Date: Sun, 11 Dec 2011 12:28:24 +0100

As an implementor of a toolkit let me offer this: the only use/requirement of mac that I've seen is for backwards compat with 1.0a. 

4 dec 2011 kl. 14:15 skrev Paul Madsen <[email-masked]>:

> Commercial OAuth authorization servers are neither 'toolkits' nor 'purpose built code' - not used to build OAuth clients/servers but yet required to support more variety in deployments than a single purpose built server.
> 
> But, that variety is driven by customer demand, and none of ours (yet?) have demanded MAC. If and when that demand comes, we will add support. 
> 
> To stipulate MAC as MTI would in no way reflect what the market wants. And 'interop' nobody wants is not meaningful interop.
> 
> paul
>

---

From: Leif Johansson <[email-masked]>
Date: Sun, 11 Dec 2011 12:30:38 +0100

> very different things. Or, citation needed.

Oauth 1.0a mac and 2.0 mac are not the same thing. Yours is an argument for backwards compat I think.

---

From: William Mills <[email-masked]>
Date: Sun, 11 Dec 2011 09:27:29 -0800 (PST)

They are only compatible in the sense that they share the same security characteristics.

________________________________
 From: Leif Johansson <[email-masked]>
To: Paul Madsen <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Sunday, December 11, 2011 3:28 AM
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type

>But, that variety is driven by customer demand, and none of ours
    (yet?) have demanded MAC. If and when that demand comes, we will add
    support. 
>
>To stipulate MAC as MTI would in no way reflect what the market
    wants. And 'interop' nobody wants is not meaningful interop.
>>OK, so here's what I suggest... I propose adding a new section 7.2, thus: -----------------------------------
7.2 Access Token Implementation Considerations Access token types have to be mutually understood among the
authorization server, the resource server, and the client -- the
access token issues the token, the resource server validates it, and
the client is required to understand the type, as noted in section
7.1, above.  Because of that, interoperability of program code
developed separately depends upon the token types that are supported
in the code. Toolkits that are intended for general use (for building other clients
and/or servers), therefore, SHOULD implement as many token types as
practical, to ensure that programs developed with those toolkits are
able to use the token types they need.  In particular, all general-use
toolkits MUST implement bearer tokens [...ref...] and MAC tokens
[...ref...]. Purpose-built code, built without such toolkits, has somewhat more
flexibility, as its developers know the specific environment they're
developing for.  There's clearly little point to including code to
support a particular token type when it's known in advance that the
type in question will never be used in the intended deployment.
Developers of purpose-built code are encouraged to consider future
extensions and to plan ahead for changes in circumstances, and might
still want to include support for multiple token types.  That said,
the choice of token-type support for such purpose-built code is left
to the developers and their specific requirements.
----------------------------------- I think that expresses a reasonable compromise that might actually be
followed and might actually do some good.  Comments?  Can we go with
this and close this issue?  (And, sorry, I've been a Bad Chair, and
haven't put this in the tracker.) Barry
_______________________________________________
OAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/oauth 
_______________________________________________

---

From: Blaine Cook <[email-masked]>
Date: Mon, 12 Dec 2011 15:10:24 +0000

> Oauth 1.0a mac and 2.0 mac are not the same thing. Yours is an argument for backwards compat I think.

The syntax is different / better, the spec is cleaner, but they
specify exactly the same thing.

I couldn't care less about all this at this point, but I do take issue
with the claim that the MAC approach in general (as typified by OAuth
1.0a and the MAC Token draft as-is) doesn't have adoption.

b.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 12 Dec 2011 19:32:00 +0100

Exactly

---

From: Barry Leiba <[email-masked]>
Date: Sun, 18 Dec 2011 14:00:34 -0500

> to the developers and their specific requirements.

We do NOT have consensus to use that text, nor any other.  As I see
it, the STRONG consensus of the working group is not to make any
change with regard to text about which tokens to use or how to
authenticate the client.  This issue is closed, and Stephen
reluctantly accepts that he's in the rough on this issue... but leaves
us with the warning that he expects other ADs, on their own, to raise
this issue during IESG evaluation.  That might result in DISCUSS
positions that we have to address at that time.

Eran, I think this gets us done with the base-doc issues, and we
should be ready for you to prepare a final version that can go into
IETF last call (unless you're aware of anything I've missed).

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 18 Dec 2011 19:04:17 +0000

> positions that we have to address at that time.

Just to confirm that the above is the case.

IMO I'm still right and the WG are still wrong:-) But let's see if
we can make progress in any case.

S