As promised, here’s a writeup about how the MPD process could handle getting RqP consent. Unfortunately, the notes weren’t able to accurately reflect the discussion, so the hope is that we can get some of that out on paper here. In UMA 1.0.x, the RqP takes the client and presumably gets sent to the AS to get an AAT. This presumes that the RqP is able to log in to the AS and authorize an OAuth client to get an OAuth token in some fashion. That AAT is then used alongside the ticket to fetch an RPT. The ticket represents the current transaction as started by the RS (so it’s got a reference to the resource set and therefore RO) and the AAT represents the client and the RqP. The client does not authenticate during this call, nor does the RqP — both of those things happened at the gathering of the AAT. In MPD, the binding happens later. The client sends the ticket to get the RPT, but now it authenticates itself to the token endpoint as part of the call. The RqP, as before, doesn’t authenticate here. In order to interact with the RqP, the AS needs to require the client to redirect the RqP to the claims endpoint. Here, the RqP can authenticate, or do any number of other interactive things required for that ticket. Either alternatively or in addition to this, the client can take a set of claims and submit them alongside the ticket to the token endpoint. One of the questions is how do we capture RqP consent in MPD? I argue that it can be done easily at the interactive claims gathering endpoint. Here, the AS can ask the RqP if they consent to allowing the client to submit claims directly on their behalf or not. That way the AS knows whether or not it should accept or reject them. Nothing we can do in either protocol can ever prevent a rogue client from spewing claims everywhere, nor can we have any insight into the claims gathering process at the client — that is all strictly out of scope and out of band in both versions. So a question is: which is more complex? In the UMA flow, in the worst case, the RqP gets sent to the AS first to authorize the client’s AAT and second to the claims endpoint to attach claims to the specific ticket. That same flow in MPD requires just one visit to the claims endpoint, so I argue it’s a much simpler UX. In the case where the client is pushing claims, then in UMA 1.0 the RqP is sent to authorize the AAT and then the client sends claims. In MPD, the RqP is sent to the claims gathering endpoint to authorize the client sending claims and then the client sends claims. It’s an equivalent UX. Are there other patterns I’m missing beyond the “interactive primary” and “back-channel-primary” ones here? So with that in mind, George brings up a great question: one thing the AAT does is that it represents a long-standing grant between the RqP and the client. At least, it’s supposed to, assuming that the AAT was gathered in an interactive fashion. But let’s say that it was. How can we replicate that longer-running process? I argue that with MPD, we can already mimic this behavior by including either an old RPT or a newly defined “UMA Refresh Token”, I’ll call it a URT, in the subsequent requests. The AS can then look at the ticket, the RPT/URT, and any claims presented by the client, and determine if all of them together make for a good enough answer to the policy on the resource set. From my personal view, I find this method significantly cleaner and less hack-ish than the AAT, since it more logically chains together multiple related transactions. If the transactions aren’t really related to each other, then what continuity does the AAT really provide? We can still identify the client strongly, by use of its client credentials. We can identify the RqP strongly by use of any number of claims binding mechanisms discussed at length. If we want to carry something like that forward throughout a transaction, then yes having a long-running token makes sense, but I would argue that we’ve either already got one (the RPT) or we should issue it along side the RPT in the RPT grant process and not in a special outside loop like the AAT was. Hope this helps, — Justin