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
