On 01/03/13 14:56, William Mills wrote:
The new signature base string stuff still needs work, I wanted to tackle more major restructuring first. I want to pull all of those things out of the query string.
Well, thanks for keeping replying, but I'm not closer to connecting the above response to the latest MAC draft than I was earlier - guess I'm not seeing a bigger picture.
Cheers, Sergey
------------------------------------------------------------------------ *From:* Sergey Beryozkin <[email protected]> *To:* William Mills <[email protected]> *Cc:* "[email protected]" <[email protected]> *Sent:* Friday, March 1, 2013 3:51 AM *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt I'm looking at [1] and I honestly don't follow what would adding JSON structure bring to the table, the text there is quite straight-forward, and the 'sorting' variable is not even there, may be, only if headers are *optionally* included when calculating 'mac'. Are you indirectly referring to the idea of OAuth2 servers supporting an OAuth1-style tokens which was proposed in the other thread by any chance, as you mention "oath_..." parameters ? In that context, using JWT extension may work, not really sure, but in context of [1] - I don't understand where it would fit in Thanks, Sergey [1] http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac/?include_text=1 On 28/02/13 18:06, William Mills wrote: > I certainly hope so. > > ------------------------------------------------------------------------ > *From:* Sergey Beryozkin <[email protected] <mailto:[email protected]>> > *To:* William Mills <[email protected] <mailto:[email protected]>> > *Cc:* "[email protected] <mailto:[email protected]>" <[email protected] <mailto:[email protected]>> > *Sent:* Thursday, February 28, 2013 10:02 AM > *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt > > On 28/02/13 17:49, William Mills wrote: > > The JWT replaces the oauth_token data element in the old MAC stuff. I > > just want to take all the other oauth_* variables and stuff them in a > > separate JSON object and completely kill the "fun with sorting > > variables" when the oauth_* things can be carried in the query string or > > header or post body. > As far as the client accessing RS is concerned, should it be limited to > using a header, same as for other OAuth2 tokens ? > > Cheers, Sergey > > > > > ------------------------------------------------------------------------ > > *From:* Sergey Beryozkin <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > > *To:* [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > > *Sent:* Thursday, February 28, 2013 9:04 AM > > *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt > > > > Hi > > On 28/02/13 13:14, William Mills wrote: > > > I'm actually advocating that we change MAC to be a JWT extension. > > IMHO, having a simpler option, plus, going forward, a possible JWT > > profile (client to RS path) would work better - > > > > Why would JWT completely take over ? May be it should be possible indeed > > to have it as a JWT extension - should it be part of the relevant JWT > > assertion spec, where JWT is used as a possible grant ? > > > > Thanks, Sergey > > > > > > > ------------------------------------------------------------------------ > > > *From:* Hannes Tschofenig <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>> > > > *To:* William Mills <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>> > > > *Cc:* Hannes Tschofenig <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>>; "[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>" > > > <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>> > > > *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: "[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> > > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>>" > > > <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> > > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>>> > > > > To: [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> > > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>> > > > > Cc: [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>> > > > > 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 > > > > [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>> > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > > https://www.ietf.org/mailman/listinfo/oauth > > > > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
