I would like to attend as well …
regards
antonio
On Sep 12, 2014, at 3:00 AM, Gil Kirkpatrick
gil.kirkpatr...@viewds.commailto:gil.kirkpatr...@viewds.com wrote:
+1 for me.
-- Original Message --
From: John Bradley ve7...@ve7jtb.commailto:ve7...@ve7jtb.com
To: Nat Sakimura
And me.
-Tiru
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Antonio Sanso
Sent: Friday, September 12, 2014 12:20 PM
To: Gil Kirkpatrick
Cc: Derek Atkins; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Authentication: What can go wrong?
I would like to attend as well ...
regards
me too
div Ursprüngliche Nachricht /divdivVon: Tirumaleswar
Reddy (tireddy) tire...@cisco.com /divdivDatum:12.09.2014 08:50
(GMT+01:00) /divdivAn: Antonio Sanso asa...@adobe.com, Gil Kirkpatrick
gil.kirkpatr...@viewds.com /divdivCc: Derek Atkins de...@ihtfp.com,
It used to be simply expires_at but after discussion on the list it was
changed to client_secret_expires_at, since the client's secret is the most
likely part to expire and need to be refreshed. Of course this refresh makes
the most sense if you're implementing the management spec where you can
Yes the JWKS expiry is logically controlled by the client. If it is going to
roll those keys it should be using a jwks_uri if there is no management API to
push a new JWKS.
In general symmetric client secrets create key management problems. My
preference is to move to asymmetric keys.
John
Okay, I see 'Changed expires_at to client_secret_expires_at and
issued_at to client_id_issued_at for greater clarity.' in the document
history for -11 (full 'management' was in the draft back then).
But to me, it doesn't improve clarity. And it seems limiting. But I seem to
be in the minority of
