Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

UMA legal subgroup notes

Notes from the 2015 series were kept in email: 2015-08-07, 2015-08-14, 2015-08-21, 2015-08-28, 2015-09-04, 2015-09-11, 2015-09-25, 2015-10-02, 2015-10-09, 2015-10-16 (need to fill in links to notes after this point).

Date and Time

No meeting 2016-01-22.

2016-01-15

Attending: Eve, Ann, Adrian, Jim, Jon, Mark, Sal, Thomas

What Eve calls the "Adrian clause" is this part of UMA Core Sec 3.3.3: "The resource server MAY apply additional authorization controls when determining how to respond."

What does the "RS authorization discretion" use case mean? Should the AS be made officially aware that the RS still didn't give access (similar to the "Shoebox" technical idea), or could the RS somehow need some other assurances that it can be compliant? This goes right back to the Adrian clause, and complementarily, to the Shoebox idea. The RS could either warn Alice, or could verify the requesting party on its own. Is this broad-based, or truly healthcare-specific? To how many jurisdictions does it apply? Adrian suggests another case of a warning. A data processing process might take some time to complete, and only licensed practitioners can receive in-process results.

Would it be useful to develop a model clause, or even a pair of model clauses? Sounds like it's useful to try, and then go back and see if it's getting used.

What does the "RO access limit discretion" use case mean? There is something of an opposite to the Adrian clause in the same section: "The resource server MUST NOT give access in the case of an invalid RPT or an RPT associated with insufficient authorization."

A way of looking at it is:

  • Conditions: RO wants sharing to happen; AS executes those directions appropriately, such that the RPT is valid and is associated with sufficient authorization data:
    • RS gives access - normal case
    • RS doesn't give access
      • To remain compliant with the law of some jurisdiction - MUST PRODUCE NOTIFICATION?
      • For some other reason - MUST NOT HAPPEN WITHIN AN UMA FLOW GOVERNED BY THE PAT MINTED WITH THE AS ABOVE?
  • Conditions: RO doesn't want sharing to happen; AS executes those directions appropriately, such that the RPT is invalid or is associated with insufficient authorization data:
    • RS doesn't give access - normal case
    • RS does give access
      • To remain compliant with the law of some jurisdiction - MUST PRODUCE NOTIFICATION?
      • For some other reason - MUST NOT HAPPEN WITHIN AN UMA FLOW GOVERNED BY THE PAT MINTED WITH THE AS ABOVE?

The idea of getting notices is that the RO could severe the relationship with the RS if they want. Of course, sometimes there are legal constraints on even getting a notification.

Can you ever trust the AS to serve the RS, versus the RO? Only at the business agreement level could an AS start to consider jurisdictional issues that RS's care about.

Please note: No meeting next week! We'll resume the week after.

2016-01-08

Attending: Eve, Ann, Jim, Adrian, Jon, Mark, Thomas, Bill Wendell (guest - ears only), Andrew Hughes, Sal

Mission and timeline discussion

A proposed mission and timeline were sent in this message.

Jon speaks in support of the three goals. Is "model clauses" the right phrase, given that "EU model clauses" is something of a term of art? We're free to call it whatever we want. RoboClauses? (smile)  Maybe the connection to EU model clauses is helpful to us.

Regarding meeting scheduling, if text review is paramount in the early going, availability of interested parties is the most key. Offline review and reporting of comments by others could work great.

"Model text" was Eve's temporary phrase covering not just the clauses but also the definition. "Model T – you can start with any color you want, as long as it's black!"

We're thinking that the "standard" meeting time of Fridays at 8am PT would be okay for starters in working on the model text. Note that Eve can't make January 22, so maybe we can move or skip that one.

Andrew's project is holding a F2F in January, and by February will possibly be really ready to need our outputs. Right now they're wrestling with different views on what "authorization" means. Is it authorization to release information? access to an API? (UMA would rely on the semantics of the API being protected for the definition.) Mark notes that consent and permission definitions should come into the picture as well. This does actually impact our term definitions because we use the word "Authorization" as part of our UMA role names, and so we may have to define Authorization, or at least define it in a limited sense so that a context in which the word is defined in a different sense is not incompatible or confusing wrt our usage. If there is, somewhere (EU?), a standard vocabulary, can we leverage it? Or is it too backwards-looking?

Let's add this to our open issues.

AI: Eve: Add model text issues to our issues backlog and tag them appropriately, including the issue of defining authorization, consent, etc.

Consenus on the mission is positive. What should our timeline actually be? Jim recommends that we target a real version number of 1.0. We can achieve this sooner rather than later if we have real review by people who really need this text!

Eve has been collecting external reviewer candidates. We did some more brainstorming.

The right time for a beta version of the model text for review: end of March 2016.

AI: Eve: Send continuing calendar invitations.

Requirements discussion

Some proposed high-level requirements were sent in this message.

Eve did a quick reading of the proposed high-level requirements. People started dropping off, but it sounded like there was at least some weak rough consensus. (smile) We'll work with this list for now until it proves problematic.

Draft model text

The latest model text for review, with commentary, was sent in this message. It lives persistently here.

We took a quick look at the message sent out.

  • No labels