Reviewer: Carl Wallace Review result: Has Nits Comments/questions - Section 2.2 states "When different common data fields are used in combination, the permissions the client requests are the cartesian product of the values." What would that mean for the example in Figure 7 where geolocation is asserted? Are data fields other than the common types not processed this way? - The MUST in the first sentence of the third paragraph in Section 3.1 should probably be a SHOULD. The paragraph before recommends against using both scope and authorization_details. The rest of the paragraph leaves open how to handle the combination (presumably including ignoring one or the other). - It is unclear to me how the "MUST consider both sets of requirements in combination with each other" language in Section 3.2 squares with the "resource parameter does not have any impact on the way the AS processes the authorization_details" language in Section 3.3 for a request that includes scope, resource and authorization_details w/locations. If scope and resource were used before, it seems odd to only consider scope during a migration period. - In section 7, the first paragraph has a MUST regarding sending "the authorization details as granted by the resource owner". The third paragraph leaves room for discretion. Should the MUST be a SHOULD? Nits - Expand AS and RS on first use - The security considerations should echo the requirement that the AS ensure that there is no collision between different authorization details types that it supports. - In section 6, the bulleted list of privileges is incomplete. The example in Section 3 also allowed for checking the status of and canceling a payment. - Section 11.1 should probably include a bullet regarding client use of the authorization_details_types metadata. - In the second paragraph of Section 12, "all strings" should probably be "all strings in an authorization_details parameter". -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
