Comments received during AMB

[xmlgrrl]

We received the following comments from Nat Sakimura during the All-Member Ballot period. The technical/editorial designations are Nat's. The letter designations are mine, for clarity and consistency with most of the previous such designations. The WG has decided to consider at least issue (a).

• a (technical): To cope with Mix-up attack etc., the claims_redirect_uri MUST be unique per AS and the authorization request MUST include it. (Potentially affects Grant Sec 3.3.2. -elm)

• b (editorial): Acronyms - The spec needs a section for all the various acronyms. Acronyms are used before they are defined so it makes reading the spec a little difficult. (Potentially affects Fig 1 in Grant Sec 1.3 and Fig 1 and the "terms and concepts" discussion in FedAuthz Sec 1.2. -elm)

• c (editorial): Some sections need more examples/concrete definitions: Grant Sec 3.3.1: claim_token & claim_token_format - ID Token format is mentioned as a possible example in claim_token_format so the ID Token as a claim_token can only be indirectly inferred. Maybe switch the order or mention this in both. Maybe some basic definitions for type/format(e.g. ID Token, SAML Assertion) should be defined.

• d (technical): Parameters - Some request/return parameters have a format/type (e.g. string/boolean) defined whereas some (e.g. PCT) doesn't say what type it is. Is that intentionally left out to be defined elsewhere?

• e (editorial): tickets input parameters: They are defined as "most recent permission ticket". I think it would be helpful to point to the section where the "most recent" one came from. Maybe point out where returned tickets can be used also. (Potentially affects Grant Sec 3.3.1 and 3.3.2. -elm)

[xmlgrrl]

Re sub-issue (a): Here is a web sequence diagram that reflects the consensus of the WG regarding whether the claims_redirect_uri to a mix-up type of attack. Our conclusion is that it is not open to such an attack. We have asked to meet with Nat to see if he concurs with the analysis. We (and he) have also identified other attack surfaces, and we have done some analysis of them; see the minutes of UMA telecon 2017-12-21 and this prior email.

[xmlgrrl]

Re sub-issue (d): The only two such parameters are ticket and pct. Both are generated and consumed by the AS, meant to represent information that is opaque to the client to which the respective value is issued, and designed to have security protections. (OAuth's state parameter, used in the opposite direction, is somewhat similar, and is defined -- in both 6749 and the UMA Grant spec -- as simply "An opaque value...".)

The format/type of permission tickets is defined in Grant Sec 5.5 (giving "a random string" as an example), and pct is defined in Grant Sec 3.3.5, with a cross-reference to Grant Sec 5.2 for an explanation of the requirement for PCT rotation.

These definitions seem sufficient for the purpose.

[xmlgrrl]

Regarding the sub-issues designed editorial, here is my take as editor, fwiw. We could re-consider these if we open up the specs again.

• (b): We decided to track RFC 6749 closely in having no section called Terminology, just an initial Roles section in Grant with hanging lists. Acronyms are introduced in Grant where they are first used in their full form, except for "RPT" and "PCT" in the diagram just before the relevant definitions. FedAuthz is a "sub-spec" of Grant and we didn't see the point of re-defining all the terms.

• (c): claim_token_format is defined as "A string specifying the format of the claim token in which the client is directly pushing claims to the authorization server" and the two parameters must appear together. We also give a (code) example just below of an OIDC claim token format. This seems sufficient. (The parameters are listed in alphabetical order, by the way.) It would be overtly connected if that sentence said claim_token instead of claim token, but it seems obvious.

• (e): "The most recent permission ticket received by the client as part of this authorization process" appears in both Grant Sec 3.3.1 and 3.3.2; complex looping is possible, which we touch on in Grant Sec 1.3.1 but otherwise leave as an exercise for deployers (or might write some extra guides for, someday). We used to have a lot more cross-referencing throughout Grant, but it seemed to be getting in the way rhetorically.

[xmlgrrl]

Belatedly recording the conclusions on sub-issue (a): We discussed it during UMA telecons 2017-12-14, 2017-12-21, and 2018-01-04, reaching consensus during the last that no specification change is required. (A new section in the UMA Implementer's Guide was added instead.)