I don't want this to sound cavalier in any way, but I wonder if this is a place where consent receipts could "paper over" a lot of sins/variances. If there is a specific reason for going against a specific set of authorization data, or lack of authorization data, in a requesting party token, then surely an accounting of exactly what the variance was, with an explanation of the delta against the exact RPT contents, would be a godsend.
A couple of thoughts on this idea:
- I doubt UMA the spec is ready yet to make a normative reference out to MVCR, but the time seems right to experiment with the idea anyway.
- Remember that the RPT that a client brought to the resource server associates that client, its requesting party, the authorization server, and that resource server; the RS may possibly have introspected it to reveal permissions (assume the default "bearer" token profile) that are associated with other resource owners, not just Alice. Any logging of permission data on Alice's behalf has to be privacy-sensitive and stick to what's relevant to her.
- Andrew's Shoebox endpoint would be handy about now, so we'd have a nice place to send the receipt. (Alice's AS could choose to host that endpoint for her.) Time for someone (in CIS WG? this one??) to sketch out that spec?
- I've observed in the past that the AS has no way, strictly speaking, of knowing whether the client actually did gain access to a resource vs. just attempted it and appeared to succeed based on observation of RPT contents vs. policy. The Shoebox endpoint would nicely do for this plain purpose ("I gave them access per this authorization data"/"I didn't give them access per this authorization data") as well as the more sophisticated purpose ("I gave them access for reason X even though they had authorization data Y"/"I didn't give them access for reason A even though they had authorization data B").
- We could have model clauses that cover each of the four circumstances so that anyone who requires reporting of whatever combination could pull in the necessary clauses.
Finally, if this is a viable approach, then indeed Allan is right, and our current clause talking about having to disallow access is all wet. :-)