On 09/03/2012 10:25 AM, Sergey Beryozkin wrote:
On 10/08/12 17:18, Dick Hardt wrote:
As an implementor, I would pick a signed JWT over OAuth 1.0A. Just
saying.
Given that, there is also a clear need for signing an HTTP(S) request
as some sites are choosing OAuth 1.0A over OAuth 2.0 because they
don't want to use bearer tokens.
I never followed what MAC solved that OAuth 1.0A did not solve. Would
someone elaborate? We do have an RFC for signing requests, there are
lots of libraries already. Why the desire to reinvent OAuth 1.0A?
I see OAuth 1.0A users starting asking why to move to OAuth 2.0,
especially now that there's a bit of concern there for some of the
users due to the recent critique of OAuth 2.0.
IMHO one of the best reasons for completing the MAC spec is to help
OAuth 1.0 users with migrating to OAuth 2.0 as the code flow + MAC is
indeed very similar to OAuth 1.0A; having different OAuth camps out
there won't be great
Very much agreed! It's a glaring hole in the capabilities of OAuth 2.0,
and one I'd like to see patched, and soon.
-- Justin
Thanks, Sergey
-- Dick
On Aug 10, 2012, at 8:00 AM, Rob Richards wrote:
I think you nailed it which that statement. Up until now it as been
back and forth about one or the other. Personally I prefer to used
layered security and not relying on a single point of attack. It's
unrealistic to say everyone is going to want/need/be able to use
(take your pick) signed/encrypted JWT. MAC at least offers an
alternative, less complicated solution.
Rob
On 8/10/12 10:41 AM, Richer, Justin P. wrote:
What about security in depth? Signing + TLS is more secure than
either alone, isn't it?
-- Justin
On Aug 10, 2012, at 3:01 AM, Hannes Tschofenig wrote:
Hi Bill,
thanks for the feedback. Let's have a look at this use case:
You need to provide me a bit more information regarding your use
case. Could you please explain
1) Who is authenticated to whom?
2) What plaintext connection are you talking about?
3) What is the problem with encrypted connections? Is this again
the "TLS has so bad performance" argument?
4) Since you are talking about cookies and making them more secure
are you trying to come up with a general solution to better cookie
security - a topic others are working on as well.
5) What is the threat you are concerned about?
Ciao
Hannes
PS: I would heavily argue against standardize a security mechanism
that offers weaker protection than bearer when the entire argument
has always been "Bearer is so insecure and we need something
stronger."
On Aug 9, 2012, at 9:43 PM, William Mills wrote:
OK, I'll play and start documenting the use cases.
Use case #1: Secure authentication in plain text connections:
Some applications need a secure form authorization, but do not
want or need the overhead of encrypted connections. HTTP cookies
and their ilk are replayable credentials and do not satisfy this
need. the MAC scheme using signed HTTP authorization
credentials offer the capability to securely authorize a
transaction, can offer integrity protection on all or part of an
HTTP request, and can provide replay protection.
-bill
From: John Bradley<[email protected]>
To: William Mills<[email protected]>
Cc: Dick Hardt<[email protected]>;
"[email protected]"<[email protected]>
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC
spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the
use-cases we are trying to address before deciding on progressing
MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver
discussion and we are going to work on the use-case/problem
description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never
agree on what it was protecting against.
I think there is general agreement that one or more proof
mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
On 2012-08-09, at 1:53 PM, William Mills wrote:
MAC fixes the signing problems encountered in OAuth 1.0a, yes
there are libraries out there for OAuth 1.0a. MAC fits in to
the OAuth 2 auth model and will provide for a single codepath
for sites that want to use both Bearer and MAC.
From: Dick Hardt<[email protected]>
To: William Mills<[email protected]>
Cc: "[email protected]"<[email protected]>
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
On Aug 9, 2012, at 9:52 AM, William Mills wrote:
I find the idea of starting from scratch frustrating. MAC
solves a set of specific problems and has a well defined use
case. It's symmetric key based which doesn't work for some
folks, and the question is do we try to develop something that
supports both PK and SK, or finish the SK use case and then
work on a PK based draft.
I think it's better to leave them separate and finish out MAC
which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they
prefer that model.
For my projects, I prefer the flexibility of a signed or
encrypted JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
