You can already filter the results of an introspection call per the introspection spec (https://tools.ietf.org/html/draft-ietf-oauth-introspection-11): The authorization server MAY respond differently to different protected resources making the same request. For instance, an authorization server MAY limit which scopes from a given token are returned for each protected resource to prevent protected resources from learning more about the larger network than is necessary for its operation. This kind of behavior is already implemented in MITREid Connect, where we don't tell an RS if the token it's introspecting has scopes outside of its purview. If you want to give the same introspection response out to everyone, and you want to deal with multiple RS's, then you can just give different tokens per RS. It's probably a good idea to do that anyway, as there's nothing in the UMA bootstrapping process that I can see that would tell a client that multiple RS's are using the same AS and RO anyway, so it has no way to combine the request to get an ubertoken in the first place. Still, it would be good if UMA were more clear on that. -- Justin On 8/5/2015 8:08 PM, Eve Maler wrote:
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
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma