Are the PCT definition(s) fully satisfying to implementers?

[xmlgrrl]

In reviewing the various pieces of the PCT definitions, AS-side and client-side, by searching through the Grant spec, I got the sense that there was something missing but couldn't put my finger on it. This is particularly true after @jricher and I discussed PCTs at CIS. They feel a bit circular. Any thoughts from others?

[xguttner]

It seems to me, that PCT is less defined than RPT, namely in terms of what it refers to and how it is upgraded. The question is, whether it is good or bad?

For RPT, there is the whole mechanism of "upgrade" described, not so for PCT. I'm unsure about:

1) What is referred to by PCT when the AS responds to the client? Definition says: "A correlation handle issued by an authorization server that represents a set of claims collected during one authorization process..." Similar in 3.3.5: "pct = A correlation handle representing claims and other information collected during this authorization process..." Does this include also the claims referred to by the PCT originally passed in the Client->AS request? If yes, then it might be worth to explicitly mention it (just for clarification, as the other source of claims is also explicitly mentioned in 3.3.3: "The authorization server MAY use interactive claims-gathering to request authorization from the requesting party for persisting claims across authorization processes. Such persisted claims will be represented by a PCT issued to the client in a subsequent step."). If no (I might be missing something?), then we can get into the situation, when a single entity will be represented by multiple PCTs and the client could not be aware of what will be relevant for what authz action (hence it might need to rotate on token EP to go through the PCTs (as there is only one per request)).

2) Is the PCT used in Client->AS request discarded when a new one is subsequently issued? Assuming a new PCT contains all the claims present in a PCT sent in the original Client->AS request, wouldn't it be easier if the old PCT is discarded (or the same identifier used for both PCTs)?

These issues are not vital, but addressing them might help to clarify the handling of PCT strings for both client and AS.

[xmlgrrl]

Thank you for the questions and comments! Some answers to your questions first:

Yes, a PCT is meant to include representation of claims passed in the client->AS request (that is, "pushed" claims along with interactively gathered ones). "Claims collection" is the general term; "claims pushing" and "interactive claims gathering" are the two submethods of collection. And "one authorization process" maps to one "run" of the protocol, so to speak, such that if the client's attempt to get an RPT either succeeds or finally errors out without a permission ticket, then a new authorization process will be started the next time the client approaches the AS, in which presenting a previously issued PCT allows the AS to correlate those associated claims and potentially leverage them if it determines they're useful. The "subsequent step" mentioned is simply the step where an RPT is issued and the optional PCT can be issued as well.

So, questions back...

Are the terms-of-art claims collection, claims pushing, interactive claims gathering, and authorization process unclear as used and (sometimes implicitly) defined? What more is needed? It does seem that "subsequent step" is easy to clarify.

The main concern seems to be about client management of PCTs, given that two distinct authorization processes are by definition not really connected until the client actually presents a previous PCT. We do have some advice in Grant Sec 3.7 and Grant Sec 5.3 about PCT management, but we don't clarify that the AS is basically expiring any PCT from a previous authorization assessment when it issues a PCT in a just-succeeding authorization assessment. Is that what's needed?

[xguttner]

Ok, the terms are pretty understandable. I was just misled by taking "claims collected" from the definition "A correlation handle issued by an authorization server that represents a set of claims collected during one authorization process..." not as a term but according to its general meaning. It probably happened because this definition occurs before actually defining the Claims collection, and the "second" definition of pct from 3.3.5 contains "...claims and other information collected..."

I would say, that according to the current version, the AS can really choose, whether to expire PCT when issuing a fresh one and the client is not forced to discard the old one.

If the similarity to refresh token is crutial, then RFC6749 - Section 6: "... the client MUST discard the old refresh token and replace it with the new refresh token. The authorization server MAY revoke the old refresh token..." You speak about even more strict behaviour - "AS is basically expiring".

I would definitely include for the PCT something like the last paragraph for RFC6749 - Section 6. The question is, whether to use MAY or MUST for the AS?

[xmlgrrl]

Per UMA telecon 2017-07-20: We agreed not to change the wording. Please see the discussion there for the rationale.