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] On Behalf Of
internet-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 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
