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
