We should be careful not to read too much into regulators' intent when it comes to mapping between UMA and PSD2. The PSD2 world, if anything, only knows about OAuth/OIDC so far. They are very likely unaware of what's possible with UMA's model -- which is why we're here to inform them. :)

Our Legal work absolutely does/should take into (ahem) account the benefits of the AS as a unique and innovative role once made separable from the RS, and I hope we will include a discussion what happens if it is not separated in practice (and how many steps of separation there really are).

All this is true no matter what vertical we're talking about.


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


On Fri, May 12, 2017 at 1:09 PM, Adrian Gropper <agropper@healthurl.com> wrote:
The intent, if not the law, behind PSD2 is to give the PSU agency over the ASPSP. As far as mapping into UMA, the framing of AISP, PISP, and TPP needs to handle:

A - The AS is federated with the ASPSP (as in OAuth / OIDC)
B - The AS is selected by the PSU from a substitutable list of regulated entities
C - The AS is owned and operated by the PSU as self-sovereign technology

A, B, and C are mutually exclusive. I think it would be clearest for UMA Legal to describe our deliverable in terms of these three options without favoring one over the other. 

Adrian


On Fri, May 12, 2017 at 1:16 PM, Eve Maler <eve@xmlgrrl.com> wrote:
http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes#UMAlegalsubgroupnotes-2017-05-12

2017-05-12

  • Reviewing draft deliverable #3 – which is now a proposal paper!

Attending: Eve, Tim, John (the koala), Mark

Tim showed us his nearly-ready latest deliverable. It's sort of deliverable #2, but it also looks a bit like a full-blown #3 because it's a proposal for a legal framework.

Elevator pitch: The User-Managed Access (UMA) technical protocol applies protection policies to permission tokens. The UMA legal framework maps those permission tokens to licenses as legal devices. This licensing mechanism is valuable to individuals, organizations, legal professionals, and privacy professionals because it allows Alice to license Bob to use her digital resources on her terms.

What do we do about the technical terms that we get from OAuth, "authorization grant", "authorization", "access" (which is colloquial, Eve believes), etc., and the legal (usually, because of regulations) term "consent"? Then there's "permission", "approval", etc. "Grant" comes from OAuth but is also, a verb, pretty neutral. The usual formulation in most regulations is "notice and consent" as a workflow. 

Mark observes that "consent to authorize (access)" could be a viable way of seeing how regulators see it. John calls UMA "an affirmative action to allow access". Eve cautions that UMA does not prescribea user experience, and it might not involve an affirmative action. Would establishment of a default policy, by an AS and not by an RO, count? That sounds like an opt-out flow.

Eve runs through the Open Banking interpretation of consent and authorization. (See this blog post.) PSD2 has terminology like this, mapped to OAuth/OIDC overlays:

  • ASPSP is, roughly, the bank (it acts as the AS/RS – in OAuth/OIDC they're in the same domain)
  • AISP (Account Information Service Provider) is like Mint
  • PISP (Payment Initiation Service Provider) is like Amazon, selling you something
  • TPP (Third Party Provider) is a client app fronting one of the last two guys
  • PSU (Payment Services User) is the resource owner

What they require for consent is that the PSU must "give consent" to the TPP (client), not the ASPSP (authorization server). This happens in a fairly complex dance that happens over two stages, concluding in an authorization code flow. So this sounds an awful lot like Mark's formulation. (smile)

BTW, the OAuth spec slipped up and accidentally used the word "consent" once.

It's a goal to make sure regulators, policymakers, and deployers can get comfortable with the notion that UMA deployments can meet "consent" requirements (as long as user experience requirements are likewise met). UX is outside the scope of the pure technical layer, but the mappings we do here can surely remark on UX where we see fit.

Tim plans to finish working on the paper over the weekend. Eve will upload it as soon as she can. Mark is doing mapping exercises in CIS WG; we should liaise on that. Also, note that the BSC DG has put in a recommendation for Kantara to consider an org-wide Legal WG, since this work is going on all over the place!


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


_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma




--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.