...
- Fridays, 8-9am PT
- Screenshare and audio: http://join.me/findthomas
- UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar
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 prescribe a 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. 
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!
2017-05-05
- Reviewing draft deliverable #3
...