Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 01 Mar 2013 11:51:08 +0000

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-masked]>
> *To:* William Mills <[email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>
> *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-masked]
> <mailto:[email-masked]>>
>  > *To:* [email-masked] <mailto:[email-masked]>
>  > *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-masked]
> <mailto:[email-masked]>
>  > <mailto:[email-masked] <mailto:[email-masked]>>>
>  > > *To:* William Mills <[email-masked]
> <mailto:[email-masked]>
>  > <mailto:[email-masked] <mailto:[email-masked]>>>
>  > > *Cc:* Hannes Tschofenig <[email-masked]
> <mailto:[email-masked]>
>  > <mailto:[email-masked]
> <mailto:[email-masked]>>>; "[email-masked]
> <mailto:[email-masked]>
>  > <mailto:[email-masked] <mailto:[email-masked]>>"
>  > > <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>
>  > > *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-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>
>  > <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>"
>  > > <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>
>  > <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>>
>  > > > To: [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>
>  > <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>
>  > > > Cc: [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>  > <mailto:[email-masked] <mailto:[email-masked]>>>
>  > > > 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-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>  > <mailto:[email-masked] <mailto:[email-masked]>>>
>  > > > https://www.ietf.org/mailman/listinfo/oauth
>  > > >
>  > > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > > _______________________________________________
>  > > OAuth mailing list
>  > > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>  > > https://www.ietf.org/mailman/listinfo/oauth
>  >
>  >
>  > _______________________________________________
>  > OAuth mailing list
>  > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>  > https://www.ietf.org/mailman/listinfo/oauth
>  >
>  >
>
>

---

From: William Mills <[email-masked]>
Date: Fri, 1 Mar 2013 06:56:19 -0800 (PST)

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.  

________________________________
 From: Sergey Beryozkin <[email-masked]>
To: William Mills <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
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:
>  > 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.
>  >
>  > ------------------------------------------------------------------------
>  > *From:* Sergey Beryozkin <[email-masked]
>  > *To:* [email-masked] <mailto:[email-masked]>
>  > *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-masked]
>  > <mailto:[email-masked] <mailto:[email-masked]>>>
>  > > *To:* William Mills <[email-masked]
>  > <mailto:[email-masked] <mailto:[email-masked]>>>
>  > > *Cc:* Hannes Tschofenig <[email-masked]
>  > <mailto:[email-masked]
>  > <mailto:[email-masked] <mailto:[email-masked]>>"
>  > > <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>  > > *Sent:* Thursday, February 28, 2013 2:28 AM
>  > > *Subject:* Re: [OAUTH-WG] I-D Action:
>  > >
>  > > 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-masked] <mailto:[email-masked]>
>  > <mailto:[email-masked] <mailto:[email-masked]>
>  > > <[email-masked] <mailto:[email-masked]>
>  > <mailto:[email-masked] <mailto:[email-masked]>
>  > > > To: [email-masked] <mailto:[email-masked]>
>  > <mailto:[email-masked] <mailto:[email-masked]>
>  > > > Cc: [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>  > <mailto:[email-masked] <mailto:[email-masked]>>>
>  > > > 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-masked] <mailto:[email-masked]> <mailto:[email-masked]
>  > <mailto:[email-masked] <mailto:[email-masked]>>>
>  > > > https://www.ietf.org/mailman/listinfo/oauth
>  > > >
>  > > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > > _______________________________________________
>  > > OAuth mailing list
>  > > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>  > > https://www.ietf.org/mailman/listinfo/oauth
>  >
>  >
>  > _______________________________________________
>  > OAuth mailing list
>  > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>  > https://www.ietf.org/mailman/listinfo/oauth
>  >
>  >
> 
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 01 Mar 2013 15:42:56 +0000

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
> *Sent:* Friday, March 1, 2013 3:51 AM
> <mailto:[email-masked]>>
>  > *Cc:* "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> <mailto:[email-masked]>
>  > <mailto:[email-masked] <mailto:[email-masked]>>>
>  > > *To:* [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>  > <mailto:[email-masked] <mailto:[email-masked]>>
> <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>>
>  > <mailto:[email-masked] <mailto:[email-masked]>>
>  > > <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>>
>  > <mailto:[email-masked] <mailto:[email-masked]>>
>  > > <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]>>>>; "[email-masked]
> <mailto:[email-masked]>
>  > <mailto:[email-masked] <mailto:[email-masked]>>
>  > > <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>"
>  > <mailto:[email-masked] <mailto:[email-masked]>>>>
>  > > > > From: "[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
> <mailto:[email-masked] <mailto:[email-masked]>>>
> <mailto:[email-masked] <mailto:[email-masked]>>>>"
> <mailto:[email-masked] <mailto:[email-masked]>>>
> <mailto:[email-masked] <mailto:[email-masked]>>>>>
> <mailto:[email-masked] <mailto:[email-masked]>>>>
>  > > > > Cc: [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
> <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>  > > <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>>
> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>  > > <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>>