So, hang on a minute here.
If the IdP is the AS, that means that the IdP is authenticating the RqP … to itself. That makes absolutely no sense, as the RqP would have a “local” account at the IdP/AS anyway and wouldn’t need or use OIDC to carry identity information to itself. So that’s particularly pointless.
Now if you’re talking about the AS being an IdP to the Client or the RS, that’s another story. However, those are separate flows entirely. The data carried on each branch of that network is quite different and it would be dangerous to conflate them. You could definitely do the id-token-as-claims bit that George mentions below in this use case, but this is NOT the same as the RqP logging into the AS using OIDC. The client is passing along an incidental artifact of authentication to prove that the RqP was at one point present at the client.
And quite frankly if you’ve got the case where the RqP has an account at the AS and you can go straight to the AS to start the flow … you don’t need UMA. Seriously, take away the claims system (because you don’t need it with a local account) and the permission ticket (which you don’t need if you strip out the AS discovery and claims systems), and you’re not doing UMA anymore. At that point, you’re much better off doing vanilla OAuth.
"But wait!”, you may say, “There’s still an RqP who is different from the RO!” To which I say: “So what?”. In any OAuth system, Alice could be given the capability to share her resources with any other identified party. If that party has a local account (is already known well by the AS) and the client doesn’t need to look up the AS at runtime, then there’s nothing that’s preventing you from building this out in a plain OAuth server’s policy engine. OAuth never states or presumes a 1:1 mapping between RO and protected resource, so it’s perfectly reasonable to use some kind of internal mechanism allowing Alice to delegate access to Bob. Bob then become the RO in the OAuth process, even if he’s been seconded the responsibility by Alice he’s playing that role now because the AS knows who Bob is already and knows Bob is allowed access. You don’t need an interoperable protocol to do that, and as we’re seeing in this conversation, the protocol is actually getting in the way.
So I think James’s use case definitely has a point, but it’s already been specified in RFC6749.
— Justin
There are lots of interesting ways to consider passing claims to the AS about the user. One we've talked about in the past is if the client authenticated the RqP with via an OpenID Connect flow, could it pass the id_token it received from the IdP to the UMA AS as a claim. The issue with this is that if we are being strict about audience checking the UMA AS has to reject the passed in id_token. What needs to happen is that the client needs to request from the IdP a token (id_token or otherwise) that is audience restricted to the UMA AS. This is viable from a flow and tech perspective, but if we want this token to be another form of "RPT" then it seems like it should have it's own token profile written to cover the use case.
Now in Jame's case, the OpenID Connect provider for the client that authenticates the RqP is the UMA AS. This is a very constrained use case though perfectly viable and maybe commonly deployed. I still think this kind of a flow should have it's own token profile as the token to the RS does not carry the same semantics as the current RPT. The current RPT binds the client, the RS and the AS together and sometimes the RqP as well. If all that's being presented is effectively an id_token, then the semantic of that token is just the RqP.
Thanks,
George
There could be a reason for an id_token to be passed back around to the same AS/IdP: There are "stateful" models for deriving identity information about the user in front of you, and alternatively "stateless" models where the information shows up with the user. There are pros and cons to each method.