That is not an issue. If you ask for adoption, we can adopt any draft with any
name.
-Original Message-
From: Ace On Behalf Of Carsten Bormann
Sent: Monday, May 18, 2020 9:12 AM
To: Ace Wg
Subject: Re: [Ace] AIF as a suggestion in key-groupcomm; AIF in MQTT
On 2020-05-18, at 17:21,
On 2020-05-18, at 17:21, Carsten Bormann wrote:
>
> [1]: https://tools.ietf.org/html/draft-bormann-core-ace-aif
Benjamin reminds me that this has -core- as the crucial third word of the draft
name.
I hope that doesn’t get in the way if we decide to pick this up as an
(informational) ACE
I have posted the minutes - review and comment as appropriate.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
As I said today, the role of AIF [1] in ACE documents can only be as a
suggestion, or as a starting point, because it assumes that the (resource)
names are static, and something application-specific has to be added for more
dynamic names.
The current MQTT proposal [2] is different in three
As I said, I have not fully thought it out. A better way to state this might
be - this token uses the same key as rather than implying overriding.
-Original Message-
From: Olaf Bergmann
Sent: Sunday, May 17, 2020 11:32 PM
To: Jim Schaad
Cc: 'Francesca Palombini' ; 'Ace Wg'
Subject:
>
> Comments are very welcome.
(1) I can’t parse
the binary
representation of the String value of ENCODED_TOKEN, which
would depend on the used charset.
What charset? JSON does not have a charset. (I’m probably misreading this.)
What *is* the “String value of
Hi Jim,
Jim Schaad writes:
> define a new claim which says - This token supersedes the token(s)
> with CWTID values of "x", "y" and "z".
Isn't this the same as token revocation with all its implications? I
would prefer strict token ordering combined with a sound revocation
mechanism. In both
