Non-voting participants:

We have quorum for this call.

#352:

James notes that only the resource registration endpoint needs the PAT, because at that time you don't yet have resource IDs (which carry resource owner context); the other two protection API endpoints involve resource IDs, which could convey the necessary RO context and could use the client credentials grant instead, avoiding the need for ROs to refresh PATs. But for anyone who hates "forever tokens" of whatever sort, they will have to bother users. That's the tradeoff. Justin opines that using the client credentials grant is tantamount to using an API key.

Eve suggested to a colleague who brought up this challenge: "The PAT does need to serve as an "offline" type of OAuth access token (which is a typical situation for them, perhaps the preponderant one). We've only given guidance that the RS has to manage TTL to ensure the outcome of keeping the PAT alive; see the FedAuthz spec and the HEART profile. If the RS can't get a permission ticket, it gives this error: a 403 Forbidden and "Warning: 199 - "UMA Authorization Server Unreachable". The RS could then, in the "competitive space", take this opportunity to initiate some refreshing action such as send a notification to the RO and ask them to re-consent to the pairing with the AS. Does that sound like a reasonable approach? If so, worth describing in the UMA Implementer's Guide?"

Cigdem points out that the PAT represents the RO's agreement for the RS to serve in this role with the AS's various endpoints, and it doesn't seem right to protect its various endpoints in different ways. Eve points out that this is relevant to the legal framework effort, since we're mapping technical artifacts to legal devices right now. The RO could revoke the PAT and that would mean the RO doesn't want the RS to use that AS for those resources anymore. James: Good point.

Since this has been brought up, it seems, multiple times  we should go back to saying a bit more in FedAuthz Sec 5.1, e.g. provide rationale and point to the UIG for some suggestions about what to do.

#341:

Eve's proposal: Keep the MUST, so that the AS always hands out a ticket, and provide some UIG suggestions about "competitive space" options for hinting. Justin points out that the client always has the choice anyway to discard the ticket and treat things as "terminal", doing a fresh resource request later (even immediately later). James would like a standard way of saying "Don't try again until...."

Do we need to invent that hinting mechanism? If we do, Justin (and Eve) still advocate that the ticket be a MUST. Justin points to the OAuth for Devices spec, which has a hinting parameter we could make use of: interval (suitably revised to change from a device code to the rotated permission ticket, and the semantic lines up really closely). Or we could use something like nbf a la JWT, though the semantic is a bit more distant and we don't have implementation experience with it for this purpose. We like keeping hints OPTIONAL.

We should also add security considerations text to Grant Sec 5.6, explaining that given that request_submitted use cases involve polling intervals, the ticket has to last long enough to give the client a chance to poll. Also, text should be added to Grant Sec 3.3.6 pointing to Sec 5.6 and mentioning that the ticket might last longer in this case because of the requirements of the request submission to the RO.

#343: Should we just mention the OAuth errors, or explicitly list them? Eve would like to list them for searching purposes. The OAuth for Devices spec (Sec 3.5) just calls out to the OAuth codes. This seems sufficient. We have consensus.

#344: We agree with the thread conclusion. These are editorial instructions.

#345: Justin says it's not invalid_request as Eve argued in the issue thread, it's actually invalid_grant because the bits and bobs of the grant request were wrong. This is an original OAuth "Bad Request" rationale. And of course the AS is supposed to document its claim token formats supported in its metadata. Is this worth pointing out explicitly as an example? Alternatively, a need_info/required_claims?claim_token_format hint could be given, if the AS and client have an understanding about hinting. Also, keep in mind that errors can leak information to attackers, and clients need to be treated as largely untrusted (they only have client credentials right up until they get RPTs (at which point they are only partially trusted).

If someone forced us to choose between invalid_grant and need_info, what would you choose? In other words, if we want to list out "invalid claim token format" as one of the conditions under a specific one of the error codes, which error code should it be listed under? We have converged on need_info?required_claims/claim_token_format. This gives the exact data the client needs in the most helpful packaging (an error description could still be supplied). We have consensus.

AI: Eve: Book one more ad hoc UMA telecon next Tuesday at 7am PT/9am CT/10am ET/3pm UK/4pm CET.

AI: Eve: Send emails about the remaining issues and send out revs 07 for review by the ad hoc.