https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not…
2019-06-18
Attending: Eve, Lisa, Thomas
Lisa has uncovered some discomfort with UCITA in communities we care about,
which may give us pause about our references to it in the Business Model
report as a source of uniform language. See this source
<http://www.ucitaonline.com/> for some of the controversy. Section 2 of our
report says "A possible challenge to implementing a user-centric access
sharing protocol has been the lack of a set of uniform default contractual
rules for the exchange of personal digital assets. Fortunately, UMA may
leverage the Uniform Computer Information Transaction Act (“UCITA”) as one
source of default contractual rules upon which the licensing of access
rights to personal digital assets may be based." We haven't yet
canonicalized *any* standard boilerplate, so we're probably not in any
danger of "exciting those antibodies", but it's something to watch out for.
Lisa notes that, from the P7012 perspective, fast progress is desired – but
when the totality of options is presented, people can easily get
overwhelmed.
Is it practical to define a Data Subject as either a natural or a legal
person, as has been suggested? Architecturally, yes, it could be. But our
analysis suggests that defining it this way is unhelpful and possibly
harmful, because:
- UMA's primary aim is to aid "Alice" the individual (a natural person)
- GDPR and many other laws/regulations/policies define data subjects as
natural persons and exclude legal persons from this role
- Conflating natural and legal persons is generally confusing
So let's stick to *Data Subject as just a Natural Person*.
We've been looking for a term for the person (Person? Natural/Legal? or
only stick to Natural?) who is in a "proxy" role in our business use cases.
If Proxy doesn't work, Tim was suggesting Representative or Legal
Representative. Examples he has provided: "Personal Representatives,
Executors, parents of minors, guardians appointed for minors, Conservators,
guardians for elders, corporate proxies, etc." While Data Subject is human,
the Representative could be a Natural or Legal Person. Given this, that's
probably a good rationale for *not* adding the word Legal on the front of
the term, since that makes it ambiguous (iow, it's a "legal representative"
whether it's a legal person or a natural person). So let's call it
*Representative*.
The point of finding and defining this name is that it's a name for a the
party when they're acting on behalf of the Data Subject, not acting in an
UMA flow capacity – even though (Representative == Resource Rights
Administrator) in the same way that (Service Provider == Relying Party) in
federated identity. The first role is about inherent value-add and the
second role is about specialty protocol dance.
In the future, we might want to have a term with a definition like this,
but we don't yet:
*(some phrase): The Legal Person to which a Protected Resource relates.*
We know there are use cases like this – "enterprise UMA" use cases. Maybe
we just say "Legal Person" for now, and we talk about the Protected
Resources that relate to them; those resources are not personal data of the
Legal Persons (though the resources may contain the personal data of
individuals).
*Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter:
@xmlgrrl
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-06-20
MinutesRoll call
Quorum was reached.
Approve minutes
-
- Approve minutes of UMA telecon 2019-03-14
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-03-14>
, 2019-03-28
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-03-28>
, 2019-04-04
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-04-04>
, 2019-04-18
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-04-18>
, 2019-05-23
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-05-23>
, 2019-005-30
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-05-30>
Approve minutes of UMA telecon 2019-03-14
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-03-14>
, 2019-03-28
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-03-28>
, 2019-04-04
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-04-04>
, 2019-04-18
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-04-18>
, 2019-05-23
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-05-23>
, 2019-005-30
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-05-30>:
APPROVED by acclamation.
Meeting times and upcoming schedule
Peter is checking his schedule to see what he can do about joining us. But
hey, he's here today, so we can hope.
We're off *Jun 27* (Identiverse) and *Jul 4* (US holiday). Business-legal
framework people: Also please note that we're off *Jul 2* (chair vacation).
Continue IETF 105 and OAuth.XYZ/transactional authorization discussion
We need to decide our plan prior to IETF 105, being held in Montreal Jul
20-26 <https://www.ietf.org/how/meetings/105/>, ideally by this call. We
haven't asked for an agenda slot at this point. Our past data/analysis
about going the Independent Submission route is in our 2015-10-15 UMA WG
telecon minutes
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-10-15> –
please read!
We're pretty concerned about mitigating risk of UMA2 changing in some kind
of backwards-incompatible way. This is a key reason why the appearance of
"XYZ" on the scene has made us do some rethinking. If there is interest in
a bigger rethinking of OAuth2 (which could take some time), we might want
to rethink UMA2 only on that time scale. In the meantime, there are some
interesting UMA2 profiles and extensions floating around.
The interesting work in IETF happens either at the three F2F meetings or on
mailing lists. If we were to turn to an Informational RFC path, that's not
a "dead end", in that it could be updated with new versions as we see fit
(the authors, not work group product). Is the Alice-to-Bob use case worked
on at all in IETF? Maybe the ACE WG is the only place, but the normative
specs don't really go there much; the Actors and Use Cases specs have some
material (see here <https://tools.ietf.org/html/draft-ietf-ace-actors-07>
and here <https://tools.ietf.org/html/draft-maler-ace-oauth-uma-00>). The
UMA WG may be frustratingly (nearly) unique in this. Then again, e.g. in
healthcare (signs around the ONC Interop Forum
<https://www.healthit.gov/news/events/interoperability-forum-3>), there
seems to be a new realization that there is little standardized other than
UMA to help with Alice-to-Bob.
What we've observed in other standards is that 5+ years are needed for true
deployment depth. SDKs, other deployment tools, profiles, extensions, and
other enablement tools are the best thing to help. JP notes that transition
into OAuth has been slow. UMA1 came out in 2015 and UMA2 came out in 2018,
so changing things is risky. Awareness is only just starting. What we
recommended at IETF 103 was:
- We propose for the OAuth WG to adopt the UMA2 specs as work items
- Operational interop and business model work currently continue at
Kantara
- The UMA WG can continue technical profiling and/or work out
transition efforts as required
- We can figure out WG-WG liaisons/communications; there are several
mutual participants
Having contributed two I-Ds, we could do the following:
1. Let the specs expire and do nothing else (beyond telling the OAuth WG
chairs that we rescind our previous proposal)
2. Decide to do an independent submission and go for an informational
RFC instead in the Security Area
3. Talk to the Application Area Directors and consider starting a new
UMA Working Group at IETF
4. Continue with our previous proposal – this one is clearly out
Are there any pros to option 3? We don't think so. The question is: Do we
want the IETF community to work on UMA, or not? (Or: Do they show any signs
at all of wanting to work on UMA?) IETF seems to specialize in security.
What privacy work it does is strictly around DNS at the moment. OIDF is
focused pretty closely on authentication of identity. Kantara does a lot
around privacy of identity/ies. We're working way up at layer-7 privacy
(and selective sharing).
A security review from the ADs could be helpful, so we're inclined towards
option 2 at the moment. We could further discuss that while still taking
action to tell the OAuth WG chairs about our decision not to press ahead
with our previous proposals (action item for Eve).
Attendees
As of 19 Jun 2019, quorum
<https://kantarainitiative.org/confluence/display/uma/Participant+Roster> is
6 of 10. (Domenico, Peter, Sal, Rich, Thomas, Andi, Maciej, Eve, Mike,
Cigdem)
1. Peter
2. Rich
3. Thomas
4. Maciej
5. Eve
6. Mike
7. Cigdem
Non-voting participants:
- Adrian
- JP Rowan (Auth0 - consultant to clients - previously at JanRain - met
Eve at IIW)
- Colin
- Alec
- Bjorn
- Nancy
- Lisa
Regrets:
- Domenico
*Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter:
@xmlgrrl
8am PT at https://global.gotomeeting.com/join/857787301
Tim has sent me some thoughts on the "Proxy" discussion; I'd like us to
sort through that. Also, Cigdem and I had a chance in London last week to
talk about how the use cases could be described with a more formal
calculus, so let's pursue that.
(And yes, we do have a "regular" WG call on Thursday -- please plan to
attend that one so we can discuss the IETF/contribution topic!)
*Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter:
@xmlgrrl
of course...
On Tue, Jun 11, 2019 at 3:29 AM Eve Maler <eve(a)xmlgrrl.com> wrote:
> Hi Adrian — I’ve left just Justin on here for the moment (since he’s on
> the UMA WG), and added Tim (as our Legal Editor). Your writeup is
> interesting. Would you be willing to send it to the UMA WG for comment
> before final publication?
>
> My only comment for now is that I’m unclear on the first delegation and
> which spec/relationship it refers to. It would be great to be able to point
> to the specific one(s) we mean in our spaghetti diagram.
>
> Eve Maler (sent from my iPad) | cell +1 425 345 6756
>
> On Jun 10, 2019, at 9:13 PM, Adrian Gropper <agropper(a)gmail.com> wrote:
>
> I've been asked to explain, in non-technical language, what the UMA
> standard is and why it's essential to many of the the conversations related
> to privacy that I'm involved in.
>
>
> https://docs.google.com/document/d/112GrR_i7HgstckRSiamlpu6scLV4dqroImFAjwD…
> tries to do that. I am cross-posting in the hope that comments either on
> the doc or on the specific discussion lists will improve this doc prior to
> public posting.
>
> TIA,
> Adrian
>
> --
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: https://patientprivacyrights.org/donate-3/
