As prep for reviewing the legal spaghetti, I propose we differentiate between an agent and a broker.

For our purposes, an agent has a fiduciary relationship with only one entity (the RO or the RqP) and is chosen by that entity. A doctor or defense lawyer are examples. A broker, on the other hand has responsibilities to both RO and RqP and may not be chosen by either. A court or hospital are examples.

When it comes to protocols implemented by an AS, the AS might be acting as either an agent or a broker. When it's an agent, it was chosen by the RO or the RqP. We probably need to deal with both options separately.

When the AS is chosen by the RO from a restricted list or a federation (not self sovereign) it could still be considered a fiduciary if it has no particular responsibility to the RqP. For example, a physician could operate an AS as an agent on behalf of her patients. The physician operated AS is chosen by the patient but it has no particular responsibilities to any requesting parties other than the public health authorities (for STDs) and law enforcement (for abuse).

When the AS is chosen from the RO as linked to hospital institutions (the use-case Alec used in the recent webinar) the hospital is typically acting as a broker and balances the privacy needs of the RO and the RqP.

Simply put, I think we have four kinds of AS:
If this covers the field, then maybe someone wants to try to explain the "cascading" protocol relationship among multiple ASs.

- Adrian



On Fri, Jul 31, 2020 at 11:30 AM Adrian Gropper <agropper@healthurl.com> wrote:


On Fri, Jul 31, 2020 at 10:56 AM Eve Maler <eve@xmlgrrl.com> wrote:
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?
The SS AS remains SS, by definition. It's up to the RO to deal with the realities of the world and to hope the AS standards highlight the issues and provide maximum tech and market leverage to the SS AS.
  • 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).
It's just another federation like Visa. There's not much new here. What's the point of standards? To make federations more powerful? To enable Mastercard to compete with Visa? The ethical issue has to do with "choice". Does the RO have meaningful choice of ASs or federations?

- Adrian

Eve Maler
Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl



On Thu, Jul 30, 2020 at 3:10 PM Adrian Gropper <agropper@healthurl.com> wrote:
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