Re: [Ace] AIF as a suggestion in key-groupcomm; AIF in MQTT
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, 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 document (I could resubmit this under a different name, but that would be confusing). Or we (ACE) could actually decide to throw this back over the fence to CoRE? Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AIF as a suggestion in key-groupcomm; AIF in MQTT
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 document (I could resubmit this under a different name, but that would be confusing). Or we (ACE) could actually decide to throw this back over the fence to CoRE? Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Interim minutes
I have posted the minutes - review and comment as appropriate. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] AIF as a suggestion in key-groupcomm; AIF in MQTT
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 ways: (1) it has different verbs (publish, subscribe) (2) it uses topic filters instead of resource names (3) it uses a text-based syntax. I think that (3) has all the usual problems, so I would recommend against this. (1) and (2) can be mapped to the structure of AIF without any pain, and I would recommend for this. In summary, essence, AIF could be made useful as the base suggestion for MQTT as well as REST, with the refinement for verbs and filters retained in the current draft. Grüße, Carsten [1]: https://tools.ietf.org/html/draft-bormann-core-ace-aif [2]: https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-04#section-3 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Update of access rights
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: Re: [Ace] Update of access rights 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 scenarios, you would still have the issue that the client forwards the superseding token/revocation message if it has a benefit from doing so. Grüße Olaf ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [ace] Fwd: New Version Notification for draft-tiloca-ace-revoked-token-notification-01.txt
>
> 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 ENCODED_TOKEN”?
(2) query parameters: diff=true and N=I are a bit redundant to each other. If
you have N, you need to have diff=true, which therefore can be omitted. diff=I
or diff (no equals sign) would therefore be simpler forms of this.
(3) Re CDDL: I read this as
token-hash = bytes
trl = [* token-hash]
diff-entry = {removed => trl, added => trl}
diff = [* diff-entry]
removed = 0
added = 1
I would simplify diff-entry as a record instead of a struct (
https://tools.ietf.org/html/rfc8610#section-2 ):
diff-entry = [removed: trl, added: trl]
i.e., leave out the labels and rely on the order in the array.
I didn’t make up CDDL for the registration response, as I don’t know what the
“…” is.
(4) Why do we need all that precision what was added and removed when?
(5) On the diff stream, please see also STP:
https://tools.ietf.org/html/draft-bormann-t2trg-stp-03
Grüße, Carsten
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Update of access rights
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 scenarios, you would still have the issue that the client forwards the superseding token/revocation message if it has a benefit from doing so. Grüße Olaf ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
