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


_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to