Thanks Denis, Yes. As currently specified, ts is an integer. My previous mail requested it to be string instead so that I can used it as a nonce generated in the style of H(timestamp|client_id|key) etc. I agree this is the place to discuss replay protection etc. (Not in JAR, which is just a container format.)
And, I have not yet posted oauth-jpop as an I-D :-) It is still in my repo only and it has got more things to be done before it can be posted. Hopefully, I can add more text and post it by Friday this week to make the deadline for the next IETF. Best, Nat On Tue, Mar 7, 2017 at 7:59 PM Denis <denis.i...@free.fr> wrote: > Hi Nat, > > I see that you are now back to the list. > > Please take note that "draft-ietf-oauth-signed-http-request-03.txt" has > expired on February 9, 2017 . > > You said: "perhaps change ts to string to accommodate nonce like string" > > In this draft, ts is defined as: > > ts RECOMMENDED. The timestamp. This integer provides replay > protection of the signed JSON object. Its value MUST be a number > containing an integer value representing number of whole integer > seconds from midnight, January 1, 1970 GMT. > > Section 7 is silent about replay protection and this is the single > instance where "ts" is mentioned in the document. > > Hence it is rather hazy to understand how to deal with this value which is > misnamed since it should rather be called: > "iat" which means "Issued At". > > A "nonce" is a concept which does not exist in OAuth 2.0 documents (but > which does exist in Open ID Connect documents). > > The core of the discussion is to explain how to achieve *replay > protection of the signed JSON object*. > > I sent an email on Fri, 17 Feb 2017 21:51:18 +0100 with the following > title : > Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwsreq-11.txt> > (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request > (JAR)) to Proposed Standard > and *I got no response*. > > Please take a look at* ITEM 1* in the email from Friday, 17 February 2017 > which addresses replay protection of the signed JSON object > and proposes a solution for OAuth 2.0 (which could be used as well by Open > ID Connect). > > I take the opportunity of this email to comment on the individual draft > you posted at: http://bit.ly/oauth-jpop > and which is called: draft-sakimura-oauth-jpop-00 > > The Abstract states: > > Only the party *in possession of* a corresponding cryptographic key with > the Jpop token can use it to get access > to the associated resources unlike in the case of the bearer token > described in [RFC6750] > <https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/Nat/oauth-rjwtprof/raw/tip/draft-sakimura-oauth-jpop.xml#RFC6750> > where any party in > possession of the access token can access the resource. > > The text should rather be changed into: > > Only the party *able to use* a corresponding cryptographic key with the > Jpop token can use it to get access > to the associated resources > > You know that in case of a collusion between clients, this method will be > ineffective. > > Simply stating in the Security Considerations section "The client's secret > key must be kept securely. " is insufficient. > > Also the text is speaking of a nonce which is not a value that has been > registered by IANA. > > > Denis > > Hi Justin, John, and Hannes > > Is there an appetite to change the draft in such a way as: > > - do not wrap access token itself. It could include at_hash though. > Rationale: Pop access token can be pretty large and I do not want to > double base64url encode. > - perhaps change ts to string to accommodate nonce like string. > > Essentially, what I want to do is not the http signing but just the pop > based client authentication, which is very simple. > > While I was writing it up, it occurred that if the above modification were > done, your draft will be a superset of what I wanted to do. > > My write up is here: http://bit.ly/oauth-jpop > > Financial API uses cases needs something like that. > (Another possibility is a sender confirmation.) > > Best, > > Nat Sakimura > > -- > PLEASE READ :This e-mail is confidential and intended for the > named recipient only. If you are not an intended recipient, > please notify the sender and delete this e-mail. > > > > -----Original Message----- > From: OAuth [mailto:oauth-boun...@ietf.org <oauth-boun...@ietf.org>] On > Behalf ofinternet-dra...@ietf.org > Sent: Tuesday, August 9, 2016 1:34 AM > To: i-d-annou...@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action: > > draft-ietf-oauth-signed-http-request-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 of the IETF. > > Title : A Method for Signing HTTP Requests for OAuth > Authors : Justin Richer > John Bradley > Hannes Tschofenig > Filename : draft-ietf-oauth-signed-http-request-03.txt > Pages : 13 > Date : 2016-08-08 > > 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:https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03 > > A diff from the previous version is available > at:https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-signed-http-request-03 > > > 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura Chairman of the Board, OpenID Foundation
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
