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!
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 does
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 rel
+1
I support adoption, as it perfectly complements the existing EST work.
So far, just one general comment:
The draft could emphasize (e.g. in the intro) that coexistence of EST and
EST-coaps is supported in target deployments. And you even may have a
combination of constrained devices in a non-
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 LwM2
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: ace@i
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 la
