https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-09-19
MinutesRoll call
Quorum was reached.
Approve minutes
-
- Approve minutes of UMA telecon 2019-08-08
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-08-08>
, 2019-09-05
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-09-05>
MOTION: Approved.
XYZ use cases
UMA-related use cases collected last time:
- *AI:* Eve: Alice-to-Alice sharing (RO-to-self)
- In Justin's description
<https://mailarchive.ietf.org/arch/msg/oauth/v8TdkruCzwH43FMKS598IC2Sheo>
of
the "multiple parties" use case (which is generally the "UMA use
case"), he
says "UMA extends this to allowing the Requesting Party to be
the one using
the client, but it generally doesn’t collapse cleanly into the
cases where
the RO *is* the party using the client since the claims gathering
endpoint and the authorization endpoint aren’t quite the same in concept."
- However, this doesn't seem right. What should happen is that RqP
(that we happen to know, if we are outside the system,
observing, that the
policy happens to match Alice-again, is the RO) should be taken
not to the
authorization endpoint but to the claims interaction endpoint.
We confirmed
that Gluu's implementation, e.g., does it this way. If there is no policy
whatsoever in place, then Alice-the-RqP's client might get, say,
request_denied and Alice-the-RO might be given the opportunity
to create a
policy for the first time that *happens* to match herself.
- *AI:* Eve: Reach out to Justin to discuss this use case.
- *AI:* Eve: Proactive Alice-to-org sharing (RO-to-client developer, so
to speak)
- *AI:* Peter: Bob is assured to a certain level that Alice is who she
says she is (strong Alice-to-AS binding or "CIBA-like")
- Transactional and long-term management of sharing of preferences with
service providers
Eve had some one-on-one discussion with Justin about the intended design
center of XYZ, transactions, and guessing what might be the impact on
client ecosystems (e.g. reducing friction or adding friction). The big
security impact is intended to be narrowing the scope and moving from
bearer to sender-constrained tokens, and doing it in a simpler and
consolidated way, hopefully easier for everyone, including clients. As we
push the boundaries of what OAuth was intended to do, it makes sense to
refactor. The rise of the Janrains and Gigyas back in the day was a
response to OAuth complexity. Anything that sits in the middle that says
"redirect to us" – a central session management service – is even simpler.
What makes it complicated is making the client smart enough to know what
profile to enact. Each profile (e.g., FAPI) has different security
characteristics. A key part of the complexity is the number of specs and
resulting amount of knowledge you need. This sounds a bit like the Active
Directory PAC (privileged attribute certificates) structure history. Do we
need one gigantic token that covers all the complexity as the solution? The
way to punch out of this paper bag is to get really familiar with all the
use cases and truly get experience with the solutions.
- Semantics for transactional-level permissions (scope and/or resource)
- This one looks covered by Justin's writeup.
- *AI:* Cigdem: Disconnected RS when a "handle" for the RS can't be
gotten right away
- XYZ has a strawman for C-to-RS
- ACE has a disconnected RS flow and doesn't use a permission
ticket – the ACE model also has a "client AS" where the client
itself might
be offline
- Liberty had a model where an offline IdP could give the client a
delegatable token that would allow the client (using the PAOS profile –
reverse SOAP...) to mint tokens in a disconnected manner – Thomas notes
that these would be considered forwardable/proxyable tickets
ACE for a time had a use case for an RS could be a proxy that could help
reach an AS for a client if either the RS or client had difficulties
getting online, but Hannes did a security analysis
<http://st.fbk.eu/sites/st.fbk.eu/files/osw2018-ace.pdf> that seemed to
cross that option off the list. Our model would seem to make this highly
unlikely to be practical if the AS and RS were loosely coupled. If you have
an entirely sender-constrained-token model such that the RS is just an SSL
tunnel between the client and AS, only then would it be safe for the RS to
proxy token issuance messages. But it seems the paper concludes this is
just unwise at all.
The last set of use cases to be documented aren't UMA conundrums at all but
simply use cases UMA actually solves over and above OAuth today:
- *AI:* Eve: Existing UMA use cases that are described in our Grant and
FedAuthz spec introductions
Next time, let's review people's use case write-ups, including Justin's
existing ones.
Nominations for chair and vice-chair
Let's take up the actual ballot next week.
Thursday meeting series
Thoughts on making this a biweekly series in Q4? Some sentiment "for".
Let's decide next week.
Attendees
As of 16 Jul 2019, quorum
<https://kantarainitiative.org/confluence/display/uma/Participant+Roster> is
5 of 9. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike, Cigdem)
1. Domenico
2. Peter
3. Maciej
4. Eve
5. Cigdem
Non-voting participants:
- George
- Vlad
- Thomas
- Colin
Regrets:
- Andi
- Mike
*Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter:
@xmlgrrl
https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not…
2019-10-01
Attending: Eve, Andi, Domenico, Nancy, Tim, Cigdem
If we are addressing a business-legal audience, should we start with a
relatively technical approach, or should we start with use cases? We do
have a challenge with people not understanding UMA. We are finding
confusion out there. We did say at the end of the last paper: "The next
papers in this series will explore *the application of UMA licensing model
to specific use cases* for various categories of owners and custodians of
personal digital assets in the global digital information society." So we
could start with a (full?) set of concrete use cases, and then work through
them step-wise.
So let's have an outline like this:
- Part 1: Introduction
- Explain UMA at a high level to a primarily business-technical
audience
- Explain technical terms in the context of State 1: RO = DS =
singular RRA
- Part 2: Delegation of Resource Rights Administration Use Cases
- Use cases written in simple language (maybe one paragraph each),
illustrating various of the DS/RO/RRA states and state changes
- A state machine showing the states and changes
- A section working through those use cases with the permission token
flows and consequences
- Part 3: Sharing relationship use cases (policies change based on
changes in relationship with RqA?)
- Subsections are like part 2's subsections...
- Part 4: Delegation of Requesting Agent Role Use Cases
- (e.g., Alice shares her connected car with Bob and he gives his
keys to her car to the valet for parking)
It's perfectly fine to blow up the text that's in the current document vs.
trying to make the existing text work. Nothing in there is sacred. Andi's
schedule has now cleared enough that he should be able to contribute
significantly for the next couple of weeks.
*Future meetings:* The call next week (*Oct 8*) is already cancelled. Eve
can't make the call on *Oct 15* but Ruth P has kindly agreed to start the
call!
*Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter:
@xmlgrrl
