All, It was suggested we define these two terms before using them in the group. Allow me to start since I brought them up, but please feel free to suggest alternate definitions. *Cascading AS* is an AS operated on behalf of an entity other than the RO herself. The RO is presumed to have chosen her AS and may have also consented to being assigned another AS as well. It's unclear which of the ASs is the cascading one or if both of them are. The term cascading AS originates from efforts to differentiate an AS that is operated by the RS as in OAuth. The difference between an OAuth AS and a cascading AS is unclear. The reason to introduce a cascading AS seems to be to limit the choices of AS to those acceptable to the RS or a federation of RSs. If there's to be another AS as well (the cascade) then the question becomes: do the RO and the RqP interact with one or both of the ASs in the cascade. It seems like we have a 2x2 matrix of choices. It would be good to understand the intent before going further. A *self-sovereign AS*, like a self-sovereign identifier (SSI), is controlled by only one entity, typically an individual, without any reliance on a federation or centralized authority. There are two benefits to operating one's own AS: (a) As a RO, you don't need to share your policies with anyone else, just the result of applying the policies to a particular request. (b) As the processor for RqP requests, you are minimizing the leakage of information about who is interested in your resources and why. Leaked information about policies or request patterns is of great value to aggregators that can process this information into inferences that are then sold as surveillance capitalism. - Adrian