AS would still be required to be HTTPS as per the spec.
________________________________
From: David Waite <da...@alkaline-solutions.com>
To: oauth@ietf.org
Sent: Thursday, August 9, 2012 4:02 PM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
For #1:
Does the use of plain HTTP to talk to protected resources provide significant
value when using an AS that requires HTTPS? Or am I misunderstanding, and this
use case would also include new modes for non-TLS communication with the AS?
For #2:
Would the signature protection just cover HTTP parameters, or would it extend
to covering any request data, such as a PUT binary file? Would the integrity
protection only cover requests, or would you also have integrity protection of
the response?
-DW
On Aug 9, 2012, at 1:37 PM, Justin Richer <jric...@mitre.org> 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>
>>>To: William Mills <wmills_92...@yahoo.com>
>>>Cc: "oauth@ietf.org" <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
>>>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
