Yes. That is my understanding. Phil
Sent from my phone. On 2013-02-28, at 9:49, Justin Richer <jric...@mitre.org> wrote: > OK, so it still runs the signature over HTTP elements (query, url, headers, > etc) but all of the structured components are *communicated* via a JWT/JOSE > structure. That makes sense to me, on the surface at least. > > -- Justin > > > On 02/28/2013 12:43 PM, William Mills wrote: >> 1) AS issues JWT + secret to client. >> 2) Client decides to access resource, creates the JWT MAC JSON object which >> contains stuff about the signature and the signature itself. >> 3) client appends that base64 encoded thing to the JWT >> >> 1) Server gets a JWTMAC token, takes apart the JWT part to get the signing >> key >> 2) Server looks at the JWTMAC to figure out what all it has to do to create >> the signature base string >> 3) server constructs the SBS computes and checks the sig. >> >> The only hairy bit right now is an arbitrary HTTP header list that may be >> included in the signature. >> >> No data in the JWTMAC is duplicated from anywhere else. >> >> From: Justin Richer <jric...@mitre.org> >> To: William Mills <wmills_92...@yahoo.com> >> Cc: Hannes Tschofenig <hannes.tschofe...@gmx.net>; "oauth@ietf.org" >> <oauth@ietf.org> >> Sent: Thursday, February 28, 2013 9:08 AM >> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt >> >> What I don't quite get is what exactly would be presented and processed at >> each step. Who needs to know what piece? We don't want to have to push >> everything into JSON for the signing to take place (that much is clear), and >> we don't want the client to be pushing the MAC secret to the RS every time >> (that would make it a lot less secret, after all). But if we can reuse JWT, >> JWS, and other JOSE mechanisms to make some parts of the MAC pattern easier >> for programmers, I'm for it. >> >> -- Justin >> >> On 02/28/2013 08:14 AM, William Mills wrote: >>> I'm actually advocating that we change MAC to be a JWT extension. >>> >>> From: Hannes Tschofenig <hannes.tschofe...@gmx.net> >>> To: William Mills <wmills_92...@yahoo.com> >>> Cc: Hannes Tschofenig <hannes.tschofe...@gmx.net>; "oauth@ietf.org" >>> <oauth@ietf.org> >>> Sent: Thursday, February 28, 2013 2:28 AM >>> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt >>> >>> Hi Bill, >>> >>> I believe you are misreading the document. In draft-ietf-oauth-v2-http-mac >>> the client still uses the MAC when it accesses a protected resource. >>> The only place where the JWT comes into the picture is with the description >>> of the access token. This matters from a key distribution point of view. >>> The session key for the MAC is included in the encrypted JWT. The JWT is >>> encrypted by the authorization server and decrypted by the resource server. >>> >>> Information about how header fields get included in the MAC is described in >>> Section 5. >>> >>> The nonce isn't killed it is just called differently: seq-nr. The stuff in >>> the original MAC specification actually wasn't a nonce (from the semantic >>> point of view). >>> The extension parameter is there implicitly by allowing additional header >>> fields to be included in the MAC computation. >>> >>> I need to look at the port number field again. >>> >>> Ciao >>> Hannes >>> >>> On Feb 27, 2013, at 11:12 AM, William Mills wrote: >>> >>> > Just read the draft quickly. >>> > >>> > Since we're now leaning on JWT do we need to include the token in this? >>> > Why not just make an additional "Envelope MAC" thing and have the >>> > signature include the 3 JWT parts in the signature base string? That >>> > object then just becomes a JSON container for the kid, timestamp, >>> > signature method, signature etc. That thing then is a 4th base64 encoded >>> > JSON thing in the auth header. >>> > >>> > How header fields get included in the signature needs definition. >>> > >>> > Why did you kill the port number, nonce, and extension parameter out of >>> > the signature base string? >>> > >>> > The BNF appears to have no separators between values. >>> > >>> > -bill >>> > >>> > >>> > From: "internet-dra...@ietf.org" <internet-dra...@ietf.org> >>> > To: i-d-annou...@ietf.org >>> > Cc: oauth@ietf.org >>> > Sent: Monday, February 25, 2013 4:46 AM >>> > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt >>> > >>> > >>> > A New Internet-Draft is available from the on-line Internet-Drafts >>> > directories. >>> > This draft is a work item of the Web Authorization Protocol Working Group >>> > of the IETF. >>> > >>> > Title : OAuth 2.0 Message Authentication Code (MAC) Tokens >>> > Author(s) : Justin Richer >>> > William Mills >>> > Hannes Tschofenig >>> > Filename : draft-ietf-oauth-v2-http-mac-03.txt >>> > Pages : 26 >>> > Date : 2013-02-25 >>> > >>> > Abstract: >>> > This specification describes how to use MAC Tokens in HTTP requests >>> > to access OAuth 2.0 protected resources. An OAuth client willing to >>> > access a protected resource needs to demonstrate possession of a >>> > crytographic key by using it with a keyed message digest function to >>> > the request. >>> > >>> > The document also defines a key distribution protocol for obtaining a >>> > fresh session key. >>> > >>> > >>> > The IETF datatracker status page for this draft is: >>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac >>> > >>> > There's also a htmlized version available at: >>> > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03 >>> > >>> > A diff from the previous version is available at: >>> > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-http-mac-03 >>> > >>> > >>> > Internet-Drafts are also available by anonymous FTP at: >>> > ftp://ftp.ietf.org/internet-drafts/ >>> > >>> > _______________________________________________ >>> > 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
