Thanks for kicking this off, Adrian.
- Are these two concepts mutually exclusive? If an RO "accepts" (or has
imposed on them) additional AS's beyond a SS AS in a cascading fashion,
then is the operation of the SS AS not SS?
- If there is a single AS in the picture, say, a multi-user AS in the
cloud that is operating on behalf of 1M RO's but also on behalf of 1000
RS's (so that it's a limited fiduciary for both), is it not-SS but also
not-cascading? In that case, what is it? I think Alec has been using the
word "community" (and maybe that's not mutually exclusive as a descriptor).
*Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter:
@xmlgrrl
On Thu, Jul 30, 2020 at 3:10 PM Adrian Gropper
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 _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma