Re: [Ace] [ace] Fwd: New Version Notification for draft-tiloca-ace-revoked-token-notification-01.txt

[Marco Tiloca <[e-mail]>]

Hi Carsten,

Thank you for this review!

We have addressed your comments in the latest version -02. Please, see
also our replies in line.

Best,
/Marco

On 2020-05-18 13:40, Carsten Bormann wrote:
>> 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”?

==>MT
We have revised Section 3 on the computation of token hashes, now giving
more step-by-step details and providing examples. Hopefully it is
clearer now.
<==

>
> (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.

==>MT
We have followed your "diff=I" suggestion and revised the interface
accordingly.
<==

>
> (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.

==>MT
We have redefined the payload format in Section 5.2 to use a record as
diff-entry, according to your suggestion.
<==

>
> I didn’t make up CDDL for the registration response, as I don’t know what the “…” is.

==>MT
We are considering the details of the registration procedure and its
response as out of scope.

ACE does not detail the registration procedure either [1][2], while
OAuth gives non-normative examples [3].

[1] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-35#section-5.3
[2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-35#section-5.6.2
[3] https://tools.ietf.org/html/rfc7591#section-3
<==

>
>
> (4) Why do we need all that precision what was added and removed when?

==>MT
This was the result of a design discussion with Jim. It is a robust way
to handle Non Confirmable notifications, as the AS would not know for
sure whether notifications were successfully delivered.
<==

>
> (5) On the diff stream, please see also STP: 
>
> https://tools.ietf.org/html/draft-bormann-t2trg-stp-03

==>MT
We did and, combined with the input from Ben at the June interim, it was
very inspiring!

We have added:

- The new Appendix A, discussing how the diff-query mode is a usage
example of the STP.

- The new Appendix B, discussing how the diff-query mode can be further
improved according to Ben's suggestion, by using the "Cursor" pattern
from the STP document. As mentioned at the June interim, it can be worth
considering this as a third mode of operation of its own.


Thanks a lot again!
<==

>
> Grüße, Carsten
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: [phone]
https://www.ri.se