Hi all,
the Client Token is a new mechanism in the ACE-OAuth that aims to solve a
scenario where the Client does not have connectivity to the Authorization
Server to obtain an access token while the Resource Server does.
The solution is therefore for the Client to use the Resource Server to
As co-author, I support adoption of the draft as WG document. There is need in
industry and multiple standardization bodies for this draft.
Regards
Sandeep
-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Jim Schaad
Sent: Tuesday, January 30, 2018 9:23 PM
To:
As a co-author, I also strongly support the adoption of this draft as a WG
document. Recall that , we already have an implementation of this draft, both
in constrained devices (SICS Contiki) and in the Nexus CA software. Recently,
we have also implemented the "integration of this draft into
On Thu, Feb 01, 2018 at 01:59:48PM +, Hannes Tschofenig wrote:
> Hi all,
>
> the Client Token is a new mechanism in the ACE-OAuth that aims to solve a
> scenario where the Client does not have connectivity to the Authorization
> Server to obtain an access token while the Resource Server
I agree with Hannes and Ben that the Client Token is speculative in nature,
solving a problem that's it's not clear that we even have. It certainly isn't
OAuth.
I already made this point in my earlier comprehensive review of the spec, but
I'll repeat again here. Please remove it!
Hi Jim,
I agree that this document should be adopted. I am willing to review
and comment.
Eli
On 30.01.18 21:23, Jim Schaad wrote:
> This is the start of a two week call for input on the adoption of the WG of
> the document draft-vanderstok-ace-est. The document has been presented at
> the
