Please find attached a detailed sequence diagram for the cascaded authorization’s main flow —i.e. when both upstream and downstream ASs are involved.

 

As for introspection, it is an interesting case. I think the downstream AS must be able to adapt/modify the upstream permissions (scopes) according to its overarching policies and combine its own permissions (scopes) with those received from the upstream AS using some kind of a configurable “introspection combining strategy.” Alternatively, it can be left to the implementers to simply decide what they want to do —although I think it must be noted in the specs as an important decision that the downstream AS must make.

The decision on the validity of the RPTs is similar. I think the validity of the downstream RPT must not exceed the validity of the upstream RPT on which basis it is issued, but again, this is something that can be left to the implementers.

 

In my current demo implementation, the downstream server simply passes on the same permissions (scopes) from the upstream server and the introspection results trickles down unmodified. But this is just a decision I made to keep things simple for this demo, while setting aside a module for “introspection combining” which currently is a simple identity function.