2019-08-06
Attending: Eve, Adrian, Cigdem, Domenico, Lisa, Nancy, Sal, Thomas, Vlad,
Tim, Colin
Cigdem sent some thinking around the "multiple DS" cases:
*Regarding multiple DS’es the table would look like this.*
*The Multiple DS case may not occur often, but is present in the case of a
shared bank account between partners.*
*When a couple opens a bank account, they may start at State 5, when one of
the couple goes under care, they transition to State 6,*
*When one of them dies, the end state is State 1 if the other partner is
the sole beneficiary, or if there is another person, it may go back to
State 5, or State 7 etc.*
*Not sure how to represent this technically – it seems to work for DS=2;
not sure it extends to a larger number.*
*Do we have cases where DS is greater than 2. *
*DS>1 | Rep>0 | Carer>0 | State*
* F | F | F | State 1: Self-management (Single DS)*
* F | F | T | State 2: Management under care (Single DS)*
* F | T | F | State 3: Co-management (Single DS)*
* F | T | T | State 4: Co-management under care (Single DS)*
* T | F | F | State 5: Self-management (Multiple DSes)*
* T | F | T | State 6: Some/All DSes under care (Multiple DSes)*
* T | T | F | State 7: Some/All DSes co-manage with Reps
(Multiple DSes)*
* T | T | T | State 8: Some or all DSes under care and
co-managed (Multiple DSes)*
If we're in State 5, but I decide to co-manage my bank account with another
party, what does my partner get to say about the situation given that they
are a DS too? What if the two partners have different accountants; does the
second partner get to/have to consent to the first partner's sharing with a
chosen accountant? Divorced parents may have different custody rights and
agendas – but this may fall under the single-DS case. Joint bank accounts
and DNA data seem to fall under the "multiple-DS" case. What use cases are
truly realistic around the RRA and sharing breakdowns beyond that? If there
are whole state machine branches that are truly not realistic, let's not
map them. Are trusts another example of potentially multi-DS and multi-RRA?
It seems so. Trusts generally are for administering physical assets, but if
they could be used for virtual assets as well, then what we're doing here
could provide real added value.
The ASO/AS role provides value in terms of the actual permissions as they
change. Right now we're focusing on the RRA/RO role changes, which are at
the "head" of UMA-technical. Is there another service/party needed,
something like a "relationship manager", to manage the state transition
stuff? In identity management, there are some solutions that do things like
this under the heading of identity lifecycle management, relationship
management, and essentially "multi-identity lifecycle management".
Thinking out loud: Three siblings open a shared account, A, B, and C. They
appoint an account manager, D, as an RRA. So each is in state 6. Brother B
decides he wants to self-manage the account, so he may need to get
permission from the others before transitioning to state 1.
Sal and Mark at OpenConsent have been doing some work on policy states and
state transitions; we will hope for a demonstration soon. We think it's
complementary.
Some concrete scenarios: This PC Magazine article
<https://www.pcmag.com/article/331910/how-to-delete-your-facebook-account>
explains
a) how to delete your Facebook account, and also b) how to request removal
of accounts for someone who is medically incapacitated and c) how to get an
account memorialized when someone dies. The latter two seem RUFADAA-like
and have very close analogues in our Cradle to Grave use cases. For
example, in use case (b), the party making the request has to prove they
have the right to be the RRA (a Rep). In use case (c), the RRA role is
self-asserted but they have to prove the DS has died.
Should we think of multiple state machines, one for every DS, and not
maintain States 5-8 as formal constructs? Does the "relationship manager"
center on resources first (e.g. the bank account) and then look up the
relevant current DS(es) and RRA(s)? Relationships tend to be graph-like,
without a single "head of the hierarchy" in reality, even if the RM isn't
using graphDB technology to manage them.
There are two *mechanisms* of state transition (not reason, but mechanism)
we might tend to see: either automatic or manual. Automatic means that you
don't need consent or any other active participation by parties for the
transition to occur. It times in (little Johnny grows up(, or a law now
goes into effect, or a sensor reports a high enough temperature, or
whatever. You might, however, need notification and other workflows. Manual
is when parties do need to take action, such as consent or permission or
setup (such as registration). Applications could need custom workflows in
either case.
Next steps: Apply the three FB use cases and Nancy's healthcare use cases
to UMA and our state machine and try to make them "work" visually and in
writing.
*We don't have a formal meeting next week.* Cigdem will inform whether she
can hold an ad hoc meeting at either our regular time or another time. We
do have a meeting on *Aug 20*.
*Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter:
@xmlgrrl
(Sorry for the delay! Hmm, the table contents don't seem to be showing
here, so please follow the link to see them.)
https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not…
2019-07-30
Attending: Eve, Andi, Cigdem, Nancy, Vladimir Prihodko (works at Lush
Group, has implemented UMA1 there), Domenico, Colin, Tim; regrets from Lisa
We examined the outputs of the ad hoc meeting of last week (in slides
<https://kantarainitiative.org/confluence/download/attachments/77300164/UMA_…>
form).
The use cases drive the state machine. So you enter it at whatever point
depending on the real-world circumstances. There's a question about which
system you're interacting with in each use case. E.g., an employee system
is an RS that holds hours worked, paid time off, etc., and personal data
management is divided up between RS's. We may have to try this with use
cases from different industries and see how it comes out. But presumably
any single "run" of the UMA protocol only involves a single cohesive system
that interoperates.
If you're operating at the technical layer, by definition it sort of all
"works out" because the protocol defines how things work, but at the policy
layer, questions creep in: having multiple ROs (RRAs) is like science
fiction (the multiple-worlds hypothesis [image: (smile)] ). If multiple
RRAs can set policy, does one's policy override another's, or do they
combine, or do they get "shares" in the policy in aggregate, or what? These
could all be different use cases. We know of some common ones, like where
the parents (or set of guardians) for a child have to all agree to release
the medical records of a child. But we don't have to figure out how to
implement this, just acknowledge that ASOs need to be free to meet the
needs of their users.
We could leverage a table as well for describing the states.
That might be a useful way to discuss those two factors in common for a lot
of the scenarios. We're not sure if there is a third dimension. Could any
one resource have RRAs that have to "split" along these lines? E.g., *Joe*
and *Jane* have a joint bank account. *Joe* is competent to self-manage
it, but *Jane* becomes ill and wants to designate a third party, not *Joe* but
her attorney *Jim*, to manage the account for her. And *then* something
happens to *Jim*... It's delegation turtles all the way down. How realistic
are some of these? There are legal constraints on continuing to add further
and further delegates. But at some level, US laws such as RUFADAA (which is
more widely adopted than ever – later Tim provided adoption status in email
<https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/vDl5Q3czO…>)
could provide a basis for at least the first layer – or maybe as far as two
layers? – of delegation to be handled at a "policy layer expressed by
technical means" with UMA's help.
Is "policy layer" the right name? The overall generic name has been
"business-legal" but that may be too awkward. Let's continue this topic.
Would it be possible to define the policies themselves to make them
interoperable? To be discussed.
Questions we still need to discuss as outlined in the slides:
For the care scenarios, do we need a primary carer/super admin type of role
or are all entities in RRA equal?
Federated authorization or not? Arguably, personas of a DS and a single DS
have the same identity verification risk. If personas, then ”DS” in the
state machine is replaced with “persona”. The key assumption: KYC works –
if that fails, all the rest fails.
*Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter:
@xmlgrrl
Our UMA2 Internet-Drafts are expiring on August 17th:
https://tools.ietf.org/html/draft-maler-oauth-umagranthttps://tools.ietf.org/html/draft-maler-oauth-umafedauthz
These drafts expire on August 17th, and while we decided not to pursue
their direct adoption in the OAuth WG as work items, we still haven't
decided on other next steps. In our 2019-06-20 telecon
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-06-20>
we did pretty much narrow down the options to two:
1. Let the specs expire and do nothing else (beyond telling the OAuth WG
chairs that we rescind our previous proposal [already done])
2. Decide to do an independent submission and go for an informational
RFC instead in the Security Area
We were leaning towards #2, but we're still open at the moment. *Please
review those meeting notes* in preparation for our call -- and feel free to
weigh in on this thread (particularly if you can't join on Thursday).
*Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter:
@xmlgrrl
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-08-01
MinutesRoll call
Quorum was not reached.
Approve minutes
-
- Approve minutes of UMA telecon 2019-06-20
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-06-20>
Deferred.
IETF 105 recap and next steps
- Especially valuable to have (potential) profile and extension authors
here to discuss
Here is the message to the OAuth list
<https://mailarchive.ietf.org/arch/msg/oauth/t-hnVfYlVJUJF_A4vKCd9pT5c8g> with
links to the two sets of meeting minutes. Video recordings are also coming
out. You can read about OAuth.XYZ <https://oauth.xyz/> here, and its
applicability to UMA use cases here <https://oauth.xyz/examples/>. The
official IETF I-D is here
<https://tools.ietf.org/html/draft-richer-transactional-authz-02>.
Questions about XYZ: Is it meant to be profilable to help it fit into a
larger ecosystem? UMA is meant for a multi-party environment. We'd want to
be sure that the rechartering effort accommodates actual UMA use cases.
Aaron P has proposed how to "add identity to XYZ
<https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz>" (iow,
layering OIDC functionality into it), but discussion with Justin so far
shows that there's an intent to incorporate UMA use cases directly; maybe
OIDC use cases would become part of it as well. Justin says all of the UMA
functionality is intended to be baked into the core protocol. Aaron P is
also considering doing a profile for IndieAuth. XYZ shouldn't have to be
profilable in the same way as OAuth2 because it doesn't have the same model
of grant types – there's not nearly as much need because there aren't as
many options. Swimlanes are coming to show how it would be used for
different purposes.
Some of the technical design basis is sourced from current UMA:
transactional handles are like permission tickets, the user interaction
approach/endpoint works the same, and the ticket given in user interactions
is like a PCT. XYZ has a C-to-AS first flow as today's OAuth does, but
there is interest among some in the OAuth group already in a C-to-RS first
flow like UMA has, and Eve and Justin have discussed how to achieve this in
a robust fashion. You would need to have the RS make a call to the
transaction endpoint and get a resource handle back to hand to the client.
Sometime in August the rechartering discussion will be picked up. It would
help to have specific UMA use cases and flows documented, within the bounds
of XYZ. "This is a use case that core OAuth2 can't handle. UMA2 can (or
even UMA2 can't), but XYZ would bring these benefits because of these
reasons: x, y, z..." Justin mentions the single-user case (Alice-to-Alice
sharing). If the client can be shown to avoid jumping through a lot of
hoops, that's a win. Things UMA2 doesn't currently handle: Strong assurance
to Bob that Alice is who she says she is (the "CIBA" case with UMA sharing
benefits). Also fully disconnected sharing.
The set of use cases would ideally be provided in the next couple of weeks
(self-imposed deadline). Justin needs four sections: a) the use case itself
(be short and to the point), b) why vanilla OAuth has limitations around
it, c) what you can achieve with extensions to OAuth (including UMA), and
d) an in-depth description of how you'd solve the use case with XYZ,
ideally with swimlanes. Roman will be picking things up again in late
August, and concrete write-ups will help keep the momentum up.
Justin's Identiverse
talk
<https://www.youtube.com/watch?v=U9i7YaN8v9c&feature=youtu.be&list=PLpKq7xRi…>
will
help people understand his spec in greater detail. Eve will ask key people
to help generate these use case write-ups.
OAuth.net/2 <http://oauth.net/2> needs UMA revision
- Anyone willing to do a quick pull request on this page to point to the
final UMA2 recommendation or our wiki home page?
Justin has done this, thanks!
- Speaking of which, our FAQ <http://tinyurl.com/umafaq> is extremely
old and out of date...
Business-legal framework update
Please read the meeting notes from this week
<https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not…>,
sent in email – we now have an emerging state machine, thanks to the work
of Cigdem, Lisa, and Nancy!
Nominations for chair and vice-chair
Nominations are open for these positions. Please send your nominations
(self or other) to Eve. She is willing to stand for chair again and Maciej
is willing to stand for vice-chair again. We'll keep these nominations open
for a while more, even though we're a bit late with the elections. You can
see the leadership team list here
<https://kantarainitiative.org/confluence/display/uma/Leadership+Team>.
The right spec link
The right spec link is UMA Grant Recommendation
<https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html>.
In addition to their having removed all the wrong robots.txt entries, we
also need to ask KI staff to link more frequently to the correct spec! This
will help search results point to the right file, which nobody is able to
find.
Attendees
As of 16 Jul 2019, quorum is 5 of 9. (Domenico, Peter, Sal, Thomas, Andi,
Maciej, Eve, Mike, Cigdem)
1. Domenico
2. Sal
3. Maciej
4. Eve
Non-voting participants:
- Scott
- Alec
- Cigdem
- Nancy
- Tim
- Colin
- Vlad
- Lisa
- Justin
- Adrian
Regrets:
- Peter
- Mike
- Maciej
*Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter:
@xmlgrrl
8am PT on Tuesday at https://global.gotomeeting.com/join/857787301
Previous notes are here. Our spreadsheet is here. Trying to access this link will send me a notification to share it with you with your preferred ID, if I haven't already given you access. Agenda item:
Working on our use case/design pattern calculus (with updates from last week’s ad hoc meeting)
And an extra reminder that, yes, we will finally have a proper “quorate” meeting on Thursday. Stay tuned for a separate note on that.
Eve Maler (sent from my iPad) | cell +1 425 345 6756
Hi Umanitarians,
This issue (most likely deferred post implementors-draft) is open for
our OpenID Connect Identity Assurance work.
https://bitbucket.org/openid/connect/issues/1097/include-legal-persons
It is addressing how to support "legal persons" within this framework.
Given all the work that UMA has done around "legal persons" I wanted to
reach out and see if there are any suggestions/recommendations.
Thanks,
George
https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not…
The spreadsheet is here
<https://docs.google.com/spreadsheets/d/1QT5LR_ibpwYwpD_XLQ1tB7OLXbdaT6Oi9aj…>
.
2019-07-16
Attending: Eve, Lisa, Domenico, Cigdem, Mark, Tim (regrets: Andi, Colin)
FYI, Eve can't make IETF 105 in person after all. She may try to attend the
OAuth.XYZ portion of it remotely (it's being presented on Tuesday next
week).
The chosen term Representative is now in the Legal Parties tab.
*AI:* Tim: Develop a suitable definition for Representative, sourced to any
legal sources as he sees fit (akin to how other definitions are done in the
original report).
What do we say about consent? We bundle a series of actions that the RRA is
"authorized to delegate" to the ASO, including "access control, consent,
and licensing functions". What does our repeated phrase "manages the
sharing of X's resources" in our use cases? With respect to UMA, it
specifically means the actions of the AS. Thinking about something like a
"vault" or "wallet", UMA doesn't have a technical entity like this, though
we know of at least one extension that does, so maybe this could come into
play officially eventually.
What is the "state" language about? It's techie language. Many of the use
cases would reflect life cycle changes, as in literally a human's life
cycle (connected to parties). These tend to be relatively slow and
predictable in the scheme of things. Permissions might need to change in
response to this. Some might be much faster and more dynamically changing,
like temperature changes or associations between people that are more
short-lived, like Uber rides or similar.
Why is UMA itself insufficient for this relationship work? UMA-based
sharing manages only what a resource owner can control. Adding the "IRM"
layer enables us to capture both all the steady states where the
"endpoints" aren't the ultimate "end parties", and all the transitions
between steady states. So our next significant work here is to define this
state machine.
*AI:* Lisa and Cigdem: Press ahead on the state machine depiction approach.
A "task force" will work on this and we will next meet two weeks from now.
*Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter:
@xmlgrrl
