Am 25.09.2010 04:22, schrieb Eran Hammer-Lahav:
OAuth 2.0 is far from being published as an RFC. I estimate it is at
least 6 months away from reaching final IESG approval, if not a year.
This is mostly due to a significant effort needed in writing and
reviewing the security considerations section which so far has
received no attention.
FYI: Mark McGloin and me started to work on the security considerations.
We will announce once we have collected and written down enough to share
with the WG.
One thing we most likely will come up with is the question how to
prevent token phishing and abuse by resource servers.
We already had a discussion about such threat scenarios in the WG when
James H. Manger brought up his sites proposal
(http://www.ietf.org/mail-archive/web/oauth/current/msg02343.html,
detailed threat description in
http://www.ietf.org/mail-archive/web/oauth/current/msg02366.html). Up to
now, we don't have a solution in the draft.
A simple signature mechanism just for this purpose (not for client
authentication, message integrity nor token/assertion integrity
protection) is one option, James's proposal would be another. Since a
lot of running code is out there for OAuth 1.0a signature, I'm fine with
John's proposal. I would just recommend to drop the client secret from
the signature calculation because not all clients will have a secret and
making client secrets avalailable to resource servers causes other
(scalability and security) problems. Using such a mechanism in
combination with HTTPS should suffice.
In my perception from IETF 78, a lot of IETF people assess OAuth to fall
back behind established IETF authentication & authorization protocols
like Kerberos in terms of security. As far as I remember people were
nearly shocked at the WG meeting to read the transmission of tokens (==
credentials) over a secure channel is just a SHOULD and not a MUST.
Moreover, the potential for token abuse became apparent instantely. In
my opinion, we should work towards security improvements otherwise
approval by IETF will be very hard.
regards,
Torsten.
We can easily lock down the bearer token portions and continue working
on the spec. The argument that it needs to be published as an RFC for
companies to deploy is both irrelevant and untrue. Facebook and
Salesforce are two examples.
If your entire argument is that waiting for a signature will delay
core, I am happy to promise that if the rest of the specification is
done, and signatures are the only thing holding it back from
publication, that we can take them out and publish.
My main issue with a separate specification is that is sends a clear
(and misguided) message that signatures are some advance and complex
thing most developers should ignore. It promoted bearer tokens to be
the preferred implementation (in practice, an implied MUST) which will
render any signature work pointless (an afterthought MAY). By putting
it in the same specification (and I have clearly demonstrated that
this can be done in under 4 pages) we give developers a complete
picture and let them choose. We also get to call out the shortcomings
of using bearer tokens and directly point to one possible alternative.
It is ridiculous how much time those opposed to signatures have wasted
by demanding justification, proposing complex replacements, or just
intentionally derailed any effort to come up with a simple signature
solution.
If we can't quickly agree on a new signature, I am going to take 1.0a
and paste it into the specification. That will be sad and pathetic,
and will ignore our responsibility to move the web forward, but its
light years better than a specification with only bearer tokens.
We have to find a quick way to compromise, or we will find ourselves
with plenty more issues to resolve. I know a few people (myself
included) who dropped their opposition to bearer tokens (especially
without requiring HTTPS) that will be inclined to bring this up again
and reopen the topic. It seems those who promote bearer tokens as the
core 2.0 protocol got everything they wanted but have not given an
inch so far.
EHL
On 9/24/10 4:26 PM, "John Panzer" <jpan...@google.com> wrote:
-1 on requiring it to be part of core OAuth2. Reasoning: It won't
be a MUST or even SHOULD requirement for either client or server,
so adding it later does not affect interop. The actual schedule
to finalize the signature mechanism should not be affected either
way -- it's fine for a WG to produce 2 or more RFCs if that's the
right thing to do. (If there were consensus today on what exactly
the signing mechanism should be I'd think differently, but I don't
believe there is.)
Caveat: If there were consensus that OAuth 2 should simply adopt
the OAuth 1.0a signature mechanism today, I'd be okay with that,
just because there is some proven code out there.
This is of course a trade-off. My bias: I really want us to
stabilize what has been spec'd so far and move forward with that
while additional work happens. There are already multiple
mutually implementations of "OAuth2" floating around and I'd
rather resolve that quickly.
--
John Panzer / Google
jpan...@google.com / abstractioneer.org
<http://www.abstractioneer.org/> / @jpanzer
On Thu, Sep 23, 2010 at 6:43 PM, Eran Hammer-Lahav
<e...@hueniverse.com> wrote:
Since much of this recent debate was done off list, I'd like
to ask people
to simply express their support or objection to including a
basic signature
feature in the core spec, in line with the 1.0a signature
approach.
This is not a vote, just taking the temperature of the group.
EHL
_______________________________________________
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
