Ah yes, I am remembering vague snatches of that Sunday meeting we had in London.
In 3.1 it states you have to use a hash function of equal size to the JWT
wrapper's. Why don't we just specify that the same function must be used?
Why include a timestamp explicitly here when we could use the Date header?
There's no nonce included in anything here, was that an explicit decision?
How is line continuation handled for header values? This should probably be
explicit about that.
Repeated headers... "Repeated header names are processed separately with no
special handling." this wants to be clearer. Does this mean you repeated a
header name in the list? (which explicitly should not be allowed). I think
this needs to explicitly say "If a header name is specified then all headers
with the same name must be processed for that header.". The next question is
ordering, will any frameworks or proxies re-order headers of the same name? If
so then we probably have to produce a sorted list of headers.
Do we need to handle repeated parameter values explicitly?
-bill
On Monday, December 22, 2014 8:26 AM, "Richer, Justin P."
<jric...@mitre.org> wrote:
Yes it did, as part of the PoP suite. It's the current stab at an HTTP
presentation mechanism for PoP tokens.
-- Justin
On Dec 22, 2014, at 11:21 AM, Bill Mills <wmills_92...@yahoo.com> wrote:
Did this get adopted as a WG item already and I missed it?
On Monday, December 22, 2014 4:33 AM, Justin Richer <jric...@mit.edu> wrote:
That's easy: any headers. That's why the signer specifies which ones. Would be
good to have since guidance tough, and examples.
-- Justin
/ Sent from my phone /
-------- Original message --------
From: Sergey Beryozkin <sberyoz...@gmail.com>
Date:12/22/2014 7:08 AM (GMT-05:00)
To: oauth@ietf.org
Cc:
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00.txt
Hi Justin
I see a fair bit of interest toward this work now being shown from my
colleagues; it would help if the next draft could clarify which HTTP
headers can be signed given it is difficult to get hold of some of HTTP
headers typically created by a low level HTTP transport component.
Thanks, Sergey
On 21/07/14 14:58, internet-dra...@ietf.org wrote:
>
> 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 : A Method for Signing an HTTP Requests for OAuth
> Authors : Justin Richer
> John Bradley
> Hannes Tschofenig
> Filename : draft-ietf-oauth-signed-http-request-00.txt
> Pages : 11
> Date : 2014-07-21
>
> Abstract:
> This document a method for offering data origin authentication and
> integrity protection of HTTP requests. To convey the relevant data
> items in the request a JSON-based encapsulation is used and the JSON
> Web Signature (JWS) technique is re-used. JWS offers integrity
> protection using symmetric as well as asymmetric cryptography.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> 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
_______________________________________________
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
