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/
(The agenda/minutes page will be updated when I'm able to log in to
Confluence.)
*Agenda*
- Roll call
- 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>
- Meeting times and upcoming schedule
- UMA interop results session at Identiverse
- Continue IETF 105 and OAuth.XYZ/transactional authorization discussion
- Business-legal framework (was business model) update
- AOB
*Minutes*
*Roll 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>
MOTION: 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>.
APPROVED by acclamation.
*Meeting times and upcoming schedule*
Peter can't make our Thursday call times, nor even Tuesdays. Dare we
renegotiate?
Q2 has been especially bad for others as well (Andi for Identiverse, Mike
for the “world tour”, identity conferences generally). Peter’s standing
conflicts are unfortunate but there will always be someone. Eve could offer
occasional ad hoc catchups (perhaps using the Friday 7am slot, particularly
if that already works for Peter) for those who persistently can’t make
(intended to be) quorate meetings, though it may mean Peter might need to
step back from his voting status if we keep the meetings where they are.
Let’s see if a second voting participant starts having problems with the
current Thursday slot and only reassess then.
We're off both *Jun 6* (chair unavailable) and also *Jun 13* (Identity Week
in London). We do have a meeting on *Jun 20*, before Identiverse.
*UMA interop results session at Identiverse*
Gluu has started to collect interop results on this page
<https://github.com/GluuFederation/UMA-interop/blob/master/interop_results.md>,
against their endpoints. So far there are results from Keycloak and
Identos, and results from WSO2 are coming. Mike reports that Identos did a
great job, even submitting PRs against the Gluu code, and not needing any
direction. Right now Gluu’s test code doesn’t have a developer on it, but
Mike is happy to have someone take over maintenance. Alec explains that the
PRs he submitted reflected “client differences”, but he hasn’t yet deployed
Gluu Gateway to test against it. There is a hosted version of the GG that
would assist in testing, so Mike is thinking about making that available.
Then we could just point people to the endpoints.
Andi is working on trying to find us an interop results report-out session.
It could be just a “BOF” type of session over lunch or something.
Alec/Identos will be at Identiverse, and could run such a session. (Yay!)
We’ll have to see how formal or informal the session might end up being,
but at least now we could say that there are some substantial results to
report, and this would stimulate more interest, more results to be
reported, and more implementations to come out of the woodwork.
Mike notes that GG is going to be re-licensed, such that it will have a
free tier in a transaction volume pricing model.
*UMA on Facebook*
FYI, we’re shutting down the UserManagedAccess Facebook page due to lack of
interest (and Eve leaving Facebook!).
Should we create some sort of LinkedIn page for UMA? It could be an
organization. Kantara <https://www.linkedin.com/company/kantara-initiative/>
has a LinkedIn page. Mike mentions that he is an UMA WG member, and can’t
link that mention to the organization. Also, any tweets from the UMAWG
handle could be posted automatically to LinkedIn as well. Things like a
mention of Mike’s blog post that he’s about to put up (about his demo of
UMA+Axiomatics XACML policies) could be on both Twitter and LI.
*AI:* Eve: Consult with Colin on the idea of making the UMA WG a LinkedIn
“company” that people can link to when they say they’re a member of it in
their profiles.
*Continue IETF 105 and OAuth.XYZ/transactional authorization discussion*
See our notes
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-05-23>
from last week. Eve reached out to both Justin and Hannes regarding our new
inclination to change what we recommended to the OAuth WG.
Thomas thinks “informational” is good because the specs would remain the
most stable, if we continue down the new path we’re thinking of. So that
would mean we would file the two UMA2 specs as informational RFCs. Mike
would prefer that any version of UMA that starts being unstable again not
be called “UMA”. Nancy comments on the amazing collaboration of subject
matter experts in the venues she has experienced. Work at the OAuth WG
level wouldn’t reflect the collaboration we’ve had here.
If we don’t see interest in adoption from the OAuth WG, on the other hand,
we might not want to stimulate too much demand in the sense that it
stimulates desire to change UMA in backwards-incompatible ways.
*AI:* Eve and Thomas: Send info to the list on what next steps would be in
turning the UMA specs into informational RFCs, especially given our
already-done contributions.
Rich mentions that there needs to be higher awareness of UMA among other
Kantara WGs. Eve points to lots of material on our wiki home page,
including “UMA 101” slide decks. Eve is willing to join WG meetings to walk
through that material as interest arises. Rich will be a liaison!
*Business-legal framework (was business model) update*
There's a new spreadsheet
<https://docs.google.com/spreadsheets/d/1QT5LR_ibpwYwpD_XLQ1tB7OLXbdaT6Oi9aj…>
reflecting
our use cases work. Our notes are kept here
<https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not…>.
Please ask to be added to the calendar invitation if you're not on it.
There are some new and interesting topics of a technical nature coming up
there.
*Attendees*
As of 28 May 2019, quorum
<https://kantarainitiative.org/confluence/display/uma/Participant+Roster>
is 5 of 9. (Domenico, Peter, Sal, Rich, Andi, Maciej, Eve, Mike, Cigdem)
1. Domenico
2. Rich Furr - new voting participant - coming out of (boring)
retirement to join us for pro bono work - 20-year career Air Force, signals
intel, biopharma (SAFE), Kantara’s birth, IAWG, HIAWG
3. Maciej
4. Eve
5. Mike
Non-voting participants:
- Adrian
- Alec
- Mark
- Nancy
- Thomas
Regrets:
- Lisa
- Cigdem
*Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter:
@xmlgrrl
(Note the change to the name of this meeting series.)
https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not…
2019-05-28
Attending: Eve, Cigdem, Domenico, Lisa, Colin, Adrian, Tim
Suggested agenda:
- Capture additional use cases people have on their minds (up to some
limit so we can get to the other items too)
- Decide what to do about "Proxy" and "Org equivalent of a Data Subject"
as legal roles
- Start to figure out/capture technical "links-to" relationships that
enable us to go from "code" to "prose"
There is work going on on a protocol called ALIAS
<https://github.com/progressive-identity/> that is built on OAuth/inspired
by UMA. Mehdi Medjaoui is involved; Eve saw a demo. She's begun discussing
with him and his colleague the potential for getting together on something
like "privacy-enhanced UMA" here based on the fact that our business model
work is going in this direction (sewing together the technology with the
legal and business layers) and folks like Identos have been extending UMA
explicitly in a similar direction. ALIAS has an artifact called a "bind
token" that cryptographically binds the RRA (ro), RSO (rs), and ASO (as)
(their version). Did Airside Mobile do something like that too?
Adrian points out that "business model" in a business context usually means
"How does this organization make money?" Other people also thought that was
the meaning. That's not what we've been meaning by it – rather, we've meant
the set of relationships that obtain among the parties (vs. the
relationships that obtain among the technical entities as defined by the
specifications). So, should we call this a "legal framework" instead?
Business-legal *<something>*? Something very important hinges on the AS-RS
separation, which conveys a main benefit. Let's try *business-legal
framework* for now and see how it feels. Is *relationships* a word we can
work with somehow? Domenico suggests *business relationships for UMA
deployment*. Sometimes Eve has used "deployment use cases" to reflect the
fact that they have concrete jurisdictions, people, companies, etc.
Do we actually need a word for "Proxy"? Our diagrams and text use cases in
the original slide deck don't seem to need it. Tim hasn't found a single
word that perfectly fits the concept, and using Proxy may not even be
legally accurate. Note that this sort of (Agency contract, Access contract)
delegation is a delegation of management, not of ultimate sharing. It's a
kind of "delegated administration for consumers". But certainly, those
liable for releasing access will want proof that the licensor has delegated
authority.
As few words as possible between the original concept and the UMA mapping,
the better! But do we still need some consistent word for the person who is
the non-data subject administrator, perhaps Representative?
Perhaps we simply need to recognize the patterns in play by adding their
relevant relationships (e.g., the addition of the relevant parties,
relationships, and legal devices). This could work elegantly. Eve will try
to convert over to that. (Cigdem has also sent thoughts to Eve.)
Adrian wonders if we have now collected enough use cases, since we've now
sussed out whether the AS or the RS is the focus of the use case. Eve's
theory is that, while there is likely a small and finite set of patterns,
it's still interesting to capture further use cases as they arise, since
real life is "messy" and we may learn from corner cases.
*Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter:
@xmlgrrl
