Hi Carsten, Thanks for the swift revision, it looks good!
On the open point: On 2021-02-17 20:56, Carsten Bormann wrote: ~snip~ >> [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? ==>MT It can be just fine to mention CWTs as "data structure" and default choice for ACE, using COSE as "cryptographic armor". Best, /Marco <== > >> 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-oauth-authz-37%23appendix-D&data=04%7C01%7Cmarco.tiloca%40ri.se%7C38b1f9b1e3074a1bc65908d8d37e128f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637491885720799437%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=amkcQPgZ7sNsoHoFBRbn%2FkJiDEEteRWq6kGWo%2Ba34nM%3D&reserved=0 > 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 > -- Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistagången 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
