Olaf and Marco (and Alexey over on the media-types mailing list), Thank you for your comments.
I have submitted an updated version that should address these comments. Please do have a quick look. A few comments on the comments: Re Marco’s comments: > * s/Constrained Devices/Constrained devices I stuck with the capitalization as these are terms of art. (I added a reference to RFC 7228 for the definitions of the terms.) > * I wonder if the following section renumbering is good to do. > > - 2.1 --> 3 > - 2.2 --> 3.1 > - 2.3 --> 4 > - 3 --> 5 > - 4 --> 6 > - etc. We did a big renumbering to arrive at the current structure (which I find quite logical); we used to have something that was closer to what you suggest. I think it is important to separate information model and data model, hence the current structure. > [Section 2] > > * I think it's worth mentioning examples of relevant "data structures" and > "cryptographic armors". Especially thinking of the ACE framework, the > capability list would be specified by the 'scope' of an protected Access > Token. I couldn’t quite act on that. Suggestions? > Can this actually be the case? At least for ACE, the AS is assumed to know > the scopes that the RS supports [1]. I read this as intended to cover also > the scope formats and data models used to express them. So, the AS would not > issue a Token with a scope that the RS does not understand in the first place. > > [1] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-37#appendix-D I didn’t discuss this, but added text to the security considerations — I believe implementations need to be able to cope with unexpected input, even if there is trust in an implementation that should not supply such. > > * In Section 5.1, some fields from [4] are missing in the registrations. Yes, Alexey also pointed this out. (My standard technique is to copy the template from somewhere else, and that failed here :-) And re Olaf’s comments: > > # 2. Information Model > > "For the purposes of this specification, the underlying access > control model will be that of an access matrix, which gives a set of > permissions for each possible combination of a subject and an > object. We do not concern the AIF format with the subject for which > the AIF object is issued, focusing the AIF object [...]" > > Here, the different use of "object" might be confusing (first as one > dimension of the access matrix, then as "AIF object", i.e., the > serialization of permission+object; in the next paragraph it is again > the first meaning of object). Maybe this can be solved by > unfolding the abbreviation: > > "[...] We do not concern the AIF format with the subject for which > the Authorization Information is issued, focusing the Authorization > Information [...]" I found it simpler to just say “AIF data item”. > Also, "AIF format" would double as "Authorization Information Format > format". I would not bother, though. Indeed, “a foolish consistency…” > s/rfc5661/RFC5661/ Only once I fixed this, idnits warned me that this is obsolete :-) Saying RFC8881 now. Thank you! I hope we can do another round before the I-D deadline. Grüße, Carsten _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
