Re: [Ace] WGLC for draft-ietf-ace-aif

[Marco Tiloca <[e-mail]>]

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&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C38b1f9b1e3074a1bc65908d8d37e128f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637491885720799437%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=amkcQPgZ7sNsoHoFBRbn%2FkJiDEEteRWq6kGWo%2Ba34nM%3D&amp;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: [phone]
https://www.ri.se