The AS as an agent of the Resource Subject (data subject)

[agropper]

The AS as an agent of the Resource Subject where there are the strongest possible constraints (technical if possible) on anyone but them (or the Grantor) seeing their policies and the RS cannot know whether the policies are under the control of either the Resource Subject or Grantor. In this context, we want to describe the limitations of liability of an RS. The issue here is that the service we would call the RS currently has visibility into an authorization sign-off by people in both the resource subject and guardian/proxy roles in some fashion, and since UMA interposes an AS as an "agent", any service becoming an UMA RS would lose this visibility. The legal questions for us are: Is this loss of visibility acceptable? If not, do we have to build a facsimile of the visibility into our model clauses? Are there jurisdictional variations?

[xmlgrrl]

Thanks for capturing this issue, Adrian! For context, this came from the UMA Legal telecon of 2016-10-07: http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes#UMAlegalsubgroupnotes-2016-10-07

[xmlgrrl]

In the current version of our Business Model (draft 7c with diagrams), the accepability question would be answered in the affirmative if the RSO has some evidence through technical artifacts that the Data Subject's delegation to the Resource Owner and through to the Authorization Server Operator can be proven. Maybe we can work through this evidence with the Consent Receipts joint work and subsequent companion papers.

[agropper]

The issue of whether the RS is dealing with the Subject or an agent of the subject overlaps to some extent with standards work on Verifiable Claims https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/topics-and-advance-readings/verifiable-claims-primer.md (AKA Verifiable Credentials). A credential is issued to a Subject but may be presented by the Subject or an agent of the Subject (the Holder).

I see UMA as complementary to Verifiable Credentials. The VC Holder is a kind of UMA AS in that both are acting as agents of the subject in interactions between VC Issuer or UMA RS and VC Inspectors and UMA RqPs. Both the Holder and the AS rely on identity claims of the Inspector or RqP to decide the scope of access to personal data that will be granted.

[xmlgrrl]

I see where you're making the parallel. It looks a bit more like the VC Holder is akin to our Resource Owner to my eye, though. It's an online actor choosing to do things like "present profiles", and "it's typically also the Subject of a credential" (in the words of the doc you linked).

[xmlgrrl]

Andi and I discussed this and figured that this may have some relevance to our Policy Manager discussion, and the person to assess this is Adrian. The idea of "RS visibility into an authorization sign-off" is where we thought there might be something, but we may be wrong. @agropper, if you could please do this assessment and turn it into some kind of decidable issue or tell us we're wrong, that would be great.

[agropper]

I re-read the comments on this issue that I myself opened and I'm confused by the legal jargon and also I was wrong and Eve caught my error on the subject of a credential above. So, I suggest we either start fresh or close the issue.

I don't see how a Policy Manager helps with this issue since the PM is active during resource registration and has no role when the the RqP shows up.

[aleclaws]

fwiw "RS visibility into an authorization sign-off" is a component of the initial UMA wallet drafts sent to mailing list. I've dropped it from the current drafts since it becomes pretty impl specific, and is probably a more... controversial topic.

Alice at her Relationship Manager

1. establishes a token for her RM to interact with the RS
2. uses the manage API to tell the RS which AS to protect her resources
3. establishes a credential for use when signing policy <--

Alice at the Policy Manager (at the time co-located with RM)

1. establishes a token from her PM to interact with the AS
2. the PM uses the Policy API to write policy signed using the RS-RO credential from 3 above

RqP during a flow

1. RqP/Client request Alices resources
2. RqP provides sufficient claims to the AS
3. Client get's an RPT and requests the resource from the RS
4. Through introspection (or the RPT) the RS can verify Alice's signature on the used policy

This makes many assumptions about what goes into the policy/what is signed/what is exchanged between the PM/AS/RS. This is again all rooted in the idea that the AS may not be Alice's direct agent, or have a direct duty to Alice.