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 <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 <mailto:internet-dra...@ietf.org>"
<internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>>
 > To: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>
 > Cc: oauth@ietf.org <mailto: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 <mailto: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

Reply via email to