Non-voting:

#337g:

The suggestion is "for failure to cascade", that is, for the token in question (permission ticket and possibly PCT) if seen again to cause the AS to kill the relevant tokens based on it. Justin notes that OAuth's experience trying to mandate this has been tricky. It requires complex long-term storage and management, and could pollute the storage with an attacker's ticket. Thus, he suggests making this just advice as a security consideration. It's essentially a health warning to AS implementers. The challenge is if the first appearance was from an attacker, causing a race condition.

The following could go in Grant Sec 5.6: "If the authorization server has reason to believe that a permission ticket is compromised, for example, because you have seen it before and you believe the second appearance is from an attacker (vs the first appearance), consider invalidating any access tokens based on it."

The following could go in Grant Sec 5.3: "The PCT is designed to be usable multiple times, so the considerations are different. "If the authorization server has reason to believe that a permission ticket is compromised, for example, if it has been supplied by a client with "impossible geography" parameters, consider not using the claims based on it."

We have consensus.

#339:

Is it already the case that RS's can't use an array if they only have one permission they want to request? That's what our problem is: Our spec language "The body of the HTTP request message contains a JSON object (for a request containing a single resource identifier) or array of objects (for a request containing more than one resource identifier)" is ambiguous. Since an RS could knock itself out and put a single object in an array anytime it wants, and the AS would have to deal, we should clarify to something like:

"...a JSON object containing one XXX or an array of one or more XXXs..."

We don't strictly have to supply an example of an array with one. Anyone who wants to do it will hunt for the wording giving them the rationale. And our rationale, for the record, is not backwards compatibility (since this is a 2.0) but optimization for requesting single permissions.

#340:

For one, it would be helpful to also do #343, which is to list all the other 6749 errors we're borrowing without changing. In this case, Justin is mentioning unauthorized_client, but that's for a broken grant type vs something else more "semantic". The unauthorized_client error would presumably be for when the client itself (vs the requesting party?) isn't authorized to access this resource. Eve's not so sure that an OAuth error meant specifically for the client shouldn't also apply to the RqP, because OAuth (without the UMA grant) doesn't know about RqPs. Justin and Andi's argument about needing to always reach for need_info (vs a definitive "not authorized" error) is that you can't ever make forward-looking statements about the state of play of policies, claims, and such -- things could turn on a dime. Cigdem notes that, regardless of this logic, it's confusing not to be able to point to some obvious "the requesting side, all of it, isn't authorized to get permissions".

Nominally, according to what we say about the OAuth invalid_grant error as interpreted by UMA, that would be it ("the client is not authorized to have these permissions added"). Justin's interpretation is literal: It's just something wrong with the client, not the RqP, and is not based on claims. So sending need_info (again), potentially repeating the same claim hints as before, would be appropriate. Sal agrees.

Andi notes that saying "Look, you're not old enough, do better next time" could be dangerous and privacy-destroying. Justin points to his previous work on claim hashing as a direction that was abandoned for the time being, for those reasons. The AS trying to be helpful can be dangerous.

We have consensus. The client is the one that needs to determine "we're done here".

Instructions: Clarify in need_info definition that this is the error to use when the client side does not meet policy.

#350:

In this case, if the requesting side didn't satisfy some of the policy, doesn't that equate to a need_info error based on our decision on #340? Actually, by the time you get to step 3 in the authorization assessment, you might have some elements that need "request submitted" treatment and some that need more requesting-side claims. Is there an order necessary between request_submitted and need_info, since the AS could ping the RO on the back channel while telling the client it needs claims, and then return request_submitted later if the RO hasn't gotten back to it? So "one of the four errors" is roughly correct. Let's put a terse Note in the spec discussing this. Consensus.

Interest in meeting tomorrow at the same time? Eve will send an invite and hope for the best. Thanks!