If you want to pack the information into the token itself (like a JWT) then you pretty obviously need to have the same token mean the same thing all over the place. In that case you’d be issuing separate tokens to separate the different systems. Unless of course you want to get crazy with a multi-party encrypted token. Either way it’s all a design choice on the part of the AS. I don’t think the upgrade flow is a good one if the client is really doing it cross-RS. I would consider it a malformed (or malicious) client that is sending a token that it’s using on one RS back to the AS to get rights to a second RS. — Justin
On Aug 5, 2015, at 11:44 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Ah, good to know. Note that not every token profile has to use the token introspection spec, however:
Core Sec 3.3.1 https://docs.kantarainitiative.org/uma/rec-uma-core.html#rfc.section.3.3.1
“Within any RPT profile, when a resource server needs to introspect a token in a non-self-contained way to determine its status, it MAY require, allow, or prohibit use of the OAuth token introspection endpoint (defined by [OAuth-introspection]) that is part of the protection API, and MAY profile its usage. The resource server MUST use the POST method in interacting with the endpoint, not the GET method also defined by [OAuth-introspection]."
(We currently point to rev 04 of that spec, and I know that’s way out of date by now...)
The ubertoken could come from a combination of the client choosing to turn in its existing token in its request for authorization data, and the authorization server choosing to respond by adding new authorization data to the existing token rather than minting a new one (basically, an upgrade pattern). This is allowed by the current wording. That’s why we were examining alternatives.
Eve
On 5 Aug 2015, at 6:27 PM, Justin Richer <jricher@mit.edu> wrote:
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