Attending: Eve, Allan, Colin, Paul, Gil, Nat The NZ POC is proceeding, and “going better and better”. ==== Looking at issues 153 and 154: The two-token idea seems attractive. One subtle change is that the old RPT contains permissions for, at most, that RqP, that client, that AS, a single RS, and all the ROs at that RS, whereas the new access token would contain permissions for, at most, that RqP, that client, that AS, all the RS’s connected to that AS, and all the RO’s using the AS that the RS’s are connected to. So the new element is the multiple RS’s. Right! If the RS introspects the access token, it’s inappropriate for it to get back any portion of the token that is targeted at other RS’s. It turns out we had to go back to UMA Core rev 03, not rev 05, to find the old two-token “HAT/RAT” model that did this: https://tools.ietf.org/html/draft-hardjono-oauth-umacore-03#section-3.3 “The AM returns the token's status in an HTTP response using the 200 OK status code, containing a JSON document supplying the token status description. The token status description either contains all of the permissions that are currently valid for this requester access token at the host in question (and thus for the requesting party on whose behalf it is acting), or indicates that the token is invalid (see Section 1.4).” It seems to break the claims/JWT model somewhat to have to filter the results of token introspection. Is there an elegant way to solve it? Allan suggests a potentially elegant way. Could the AS only ever hand out (or upgrade) access tokens per RS? We already do have language in Core that has the “feel” of what we want to achieve: https://docs.kantarainitiative.org/uma/rec-uma-core.html#rfc.section.3.4 “If the client did not present an RPT in the request for authorization data, the authorization server creates and returns a new RPT. If the client did present an RPT in the request, the authorization server returns the RPT with which it associated the requested authorization data, which MAY be either the RPT that was in the request or a new one.” We could use this style of spec language to mandate that the authorization server MUST (or, as a privacy consideration, SHOULD?) issue new RPTs/access tokens. SHOULD seems way too weak. Nat points out that it’s a security leak as well, since it’s a bearer token. Nat observes that in OIDC, you have the same kind of constraint, so this seems like a reasonable way to handle the constraint. Naturally, we noted, whatever token profile you define, it has to be opaque to the client. ==== Looking at issue 165: We poked around at the various disconnects here: RS’s don’t know anything about clients, by design. On the other hand, clients are operated by parties who aren’t the resource owner, and are generally expected to “take what they get”. On the third hand, clients might be capable of working with only some subset of scopes, and know better than AS’s what they can handle. The requested-permission-and-ticket flow is a natural place that suggests itself for extension, either for client hints to the RS or client requests to the AS. Another possibility, suggests Allan, is for the client to have a completely new and additional way to construct tickets (or, said another way, to request permissions?) of its own directly. We didn’t take this too far — just “woke up the topic” a little. Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com