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