+1
We've supported #3 for quite some time in our public APIs that pre-date
OAuth.
Thanks,
George
On 8/9/12 3:37 PM, Justin Richer wrote:
Use case #2: signature protection over plain HTTP parameters
MAC gives us message-level signing in a way that doesn't require all
the parameters to be packed into an extra structure, like JWT/SAML do.
TLS gives no application-layer verification of integrity of
parameters, nor does it give you the ability to know who presented
those parameters (unless you're doing mutual TLS, which nobody does).
MAC gives you a fairly simple way to protect all parameters on a call
to the resource server while still keeping all of those parameters in
their native HTTP forms.
Use case #3: generic signed HTTP fetch (not directly addressed by MAC
spec as of today)
Sometimes you want to create a URL with one service, fix all of the
parameters in that URL, and protect those parameters with a signature.
Then that URL can be passed to an untrusted service who cannot modify
any portion of it. Nor can they re-use the signature portion to
protect different parameters. We do this today with a 2-legged OAuth
signature across a service URL. The "Client" generates the signed URLs
and passes them to a user agent which actually does the fetch to the
service.
-- Justin
On 08/09/2012 02: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 <ve7...@ve7jtb.com>
*To:* William Mills <wmills_92...@yahoo.com>
*Cc:* Dick Hardt <dick.ha...@gmail.com>; "oauth@ietf.org"
<oauth@ietf.org>
*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 <dick.ha...@gmail.com <mailto:dick.ha...@gmail.com>>
*To:* William Mills <wmills_92...@yahoo.com
<mailto:wmills_92...@yahoo.com>>
*Cc:* "oauth@ietf.org <mailto:oauth@ietf.org>" <oauth@ietf.org
<mailto:oauth@ietf.org>>
*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
OAuth@ietf.org <mailto: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
