Hiya,
On 12/04/2011 06:51 PM, Eran Hammer-Lahav wrote:
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.
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.)
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.
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.
EHL
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Stephen Farrell
Sent: Sunday, December 04, 2011 6:44 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type
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
On 12/04/2011 02:21 PM, Mike Jones wrote:
The core spec should be completely silent on MAC, as it is not ready for
prime time.
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Stephen Farrell
Sent: Sunday, December 04, 2011 6:20 AM
To: Paul Madsen
Cc: oauth@ietf.org
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:
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
On 12/3/11 4:37 PM, Barry Leiba wrote:
Stephen says:
On 12/02/2011 03:20 AM, Barry Leiba wrote:
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.
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
