Hi,
Here is the deck I plan to use to talk about UMA at IIW the week of 10/24.
Any feedback gladly accepted:)
http://www.slideshare.net/CloudIDSummit/cis-2015-user-managed-access
Thanks,
George
--
Distinguished Engineer
Identity Services Engineering, AOL Inc.
Mobile:+1-703-462-3494 Office:+1-703-265-2544
http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note…
2016-10-07
- Working session on User-Managed Access (UMA) in Contractual and
Regulatory Contexts
<https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…>
Attending: Eve, Kathleen, Adrian, Mary
Let's do some use case work today.
Kathleen notes that, working with the US feds, there's a difference between
a "contract" and a "memorandum of understanding" (MOU). In an MOU, they're
funding a program, so some transaction value is flowing. Many types of
contracts do capture some sort of payment. Maybe this has to do with the
relationship being formed, and therefore impacts the model clauses most
forcefully.
Analogously to the Grantee/Resource Subject split, we anticipate there
needs to be a Grantor/*something* split, where there's potentially someone
who might request and get access as part of an employment contract on
behalf of the real party who's accountable for the access (like the doctor
or admin who works for a hospital). Mary brings up "*Relying Party*" as a
candidate for the opposite side of the Resource Subject. Eve has some
discomfort because it may cause confusion between identity federations and
access federations. But what if the analogy with the sharing specifically
of personal data is so powerful that this phrase evokes the right images?
Or maybe *Receiving Party*? *Resource Recipient*?
RO-side use cases, summarized:
- UC1: RO = Grantor = Resource Subject, where this natural person has
legal capacity
- UC2: RO = Grantor, where Resource Subject is a natural person without
legal capacity
- UC3: RO = Grantor, where Resource Subject is a natural underage person
unable to consent online (yet) and they are also a RqP
- We need a *UC3a* that maps what happens when the underage person
becomes of age
- UC4: RO = Grantor, where ...
What are the RqP-side analogies? Let's try and fill those out next time. We
need to build out these lists for every technical role.
AS-side use cases: Adrian's main concern is the AS as an agent of the
Resource Subject or Grantor, where there are the strongest possible
constraints (technical if possible) on anyone but them seeing their
policies and the RS cannot known whether the policies are under the control
of either the Resource Subject or Grantor. In this context, he wants to
describe the limitations of liability of an RS. The issue here is that the
service we would call the RS currently has visibility into a sign-off by
people in both the resource subject and guardian/proxy roles in some
fashion, and since UMA interposes an AS as an "agent", any service becoming
an UMA RS would lose this visibility. The legal questions for us are: Is
this loss of visibility acceptable? If not, do we have to build a facsimile
of the visibility into our model clauses? Are there jurisdictional
variations?
*AI:* Adrian: Add the above as a GitHub issue
<https://github.com/KantaraInitiative/wg-uma/issues>.
PARKING LOT: One thing we should discuss at some point is the notion of
"pushing" content" vs. a typical web pattern of "pulling" content. The
usual web pattern we think of is that a client approaches an API
unilaterally, which is nominally a "pull". However, there are patterns such
as websocket where there is a constantly open channel through which the RS
could push content at will. The IoT uses this a bunch, and some other
technologies. Kathleen mentioned the AS serving as a content broker – we'd
have to discuss what this means more.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Dear UMA workgroup members,
I have joined the UMA working group a few days ago.
I am a Senior Researcher in Nominet R&D working on the privacy in the Internet of Things. Nominet, as its core business, is the official registry of the .uk domain names. The R&D group explores emerging technologies and engages in applied research. Our current focus is on Internet of Things, Smart Cities, and TV White Space.
My main expertise is network protocols and mobile and wireless networks. In the past year, I have been researching on UMA and experimenting with how it fits with our IoT projects.
For more information about me: https://uk.linkedin.com/in/cigdemsengul
You can find a list of our IoT projects in: http://www.nominet.uk/emerging-technology/internet-of-things-tools/
General R&D: http://www.nominet.uk/emerging-technology/
Sincerely,
Cigdem Sengul, PhD
Senior Researcher
[cid:image001.png@01D22075.2F7E1420]
Website<http://www.nominet.uk/> | Twitter<https://twitter.com/Nominet> | Facebook<https://www.facebook.com/nominet/>
DD: +44 (0)1865 332256 E: cigdem.sengul(a)nominet.uk
Minerva House, Edmund Halley Road, Oxford Science Park, Oxford, OX4 4DQ, United Kingdom
Nominet UK. Registered in England and Wales No. 3203859
This message is intended exclusively for the individual(s) to whom it is addressed and may contain information that is privileged, or confidential. If you are not the addressee, you must not read, use or disclose the contents of this e-mail. If you receive this e-mail in error, please advise us immediately and delete the e-mail. Nominet UK has taken every reasonable precaution to ensure that any attachment to this e-mail has been swept for viruses. However, Nominet cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment.
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-06
MinutesRoll call
Quorum was reached.
Logistics
The call for *the week after next* will be held *Fri Oct 21* instead of *Thu
Oct 20*, just after the Legal subgroup call.
Next week we'll have an 04 within which we should have a permission ticket
flow for the RS wherein which there will be a framework for the client to
theoretically be able to ask for scopes for multiple resource sets by the
time it gets to the AS.
Approve minutes
Approve minutes of UMA telecon 2016-09-22
<http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-22> :
APPROVED by acclamation.
IIW
The UMA video <https://www.youtube.com/watch?v=U3mZmzVOAqE> is up! Is it
better to consolidate all links to one channel, or put the video on
multiple channels? Inconclusive. Do we want to start a Vimeo channel as
well? Let's not.
Phil has given us an opportunity to do a pre-planned UMA 101 session at
IIW. George is giving the session. Others here can provide feedback.
NOTE: Please give an "IP policy benediction" at the start of any UMA
content-related sessions. Here's the IPR policy
<http://kantarainitiative.org/confluence/pages/viewpage.action?pageId=410256…>
and
here's the joining form
<http://signup.kantarainitiative.org/?selectedGroup=11>; you could print
them out or distribute the links for people's convenience.
Work on UMA.next issues
We need to look at the security considerations of the PCT. It's a bit like
a refresh token, in that it's got extra power over an access token and so
must be wielded carefully. Could hijacking and replaying a PCT be bad? It's
bound to the client credentials like a refresh token would be, but the
point is to go get an access token without having to present (or have the
RqP get pumped through interactions for) a whole bunch of claims all over
again.
In the terminology definition, do we want to go into more detail about the
intended usage, or is the existing (fairly large already) detail about the
"claim components" of the PCT okay? Sec 1.3.2 has more about the intended
usage, similar to the previous AAT description.
Regarding the "[ISSUE: what about at the same or a different resource
server?]", the answer is that it's immaterial wrt the resource server, just
as it was for the AAT.
Regarding issue #251
<http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-17>,
the telecon notes were not accurate. Unguessable and unforgeable by an
attacker is the only requirement; securely random would be one way to meet
the requirement. Mike suggests pointing to OAuth Sec 10.10
<https://tools.ietf.org/html/rfc6749#section-10.10> – or maybe we could
leverage its wording – to get the right effect. The specific wording we
like is "The authorization server MUST prevent attackers from guessing
access tokens, authorization codes, refresh tokens, resource owner
passwords, and client credentials." Say this in the security
considerations, or for each token/ticket/thingie? See below.
Spec instructions:
- Add some security considerations around PCTs, including why the client
has to make a "best effort"
- Remove the [ISSUE] above and fill in the language
- Regarding "same requesting party as previously", change to "same as
the previous requesting party".
- Say "unguessable" as the definition for each token/ticket and then
require the one-paragraph version of unguessability once in the security
considerations.
Next time, we'll look at Domenico's diagrams for UMA grant flows.
Next time, for set math discussions:
*What does the RS have to do at permission ticket registration time?* What
is the RS's motivation for registering anything at all? Its only context is
what access the client attempted.
*Can the client request scopes from the RS (in addition to just attempting
access)? *No.
*How does the client request scopes from the AS, and what can it ask for
(e.g., what interaction does it have if it wants multiple resource sets)?*
The question we need to ask at each messaging stage to get the semantics
for each actor correct, and crystal-clear, is: What is the context, and
"what's my motivation?" [image: (smile)]
Attendees
As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert,
Maciej, Eve, Jeffrey, Mike, Sarah)
1. Domenico
2. Andi
3. Robert
4. Maciej
5. Eve
6. Mike
7. Sarah
Non-voting participants:
- Andrew
- François
- Kathleen
- James
- Justin
- Scott F
- Jin
- John W
- Adrian
- George
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
I've already moved the calendar entry from Thu Oct 20 at 9am PT to Fri Oct
21 at 9am PT, just after the legal call. I checked, and it looks like
Europe, at least, won't have shifted off summertime yet. The calendar is
here if you haven't subscribed to it yet:
http://kantarainitiative.org/confluence/display/uma/Calendar
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Draft 03 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-03.html>.
We're starting to make enough invasive changes that reading it through more
comprehensively is a good idea, but here are the difference sets
<https://github.com/KantaraInitiative/wg-uma/commits/mpd-edits> to pay
close attention to:
- First wave of edits
<https://github.com/KantaraInitiative/wg-uma/commit/c7982502dc87557509dc5b21…>
after last Thursday
- Ignore the trivial stuff and hunt for lines 288, 392, 418, 1196
(edited more just below), 1307 (a bit)
- In future, I'll try and isolate that extra-space stuff into a
separate commit
- Second wave of edits
<https://github.com/KantaraInitiative/wg-uma/commit/9316db4f5202d163e11aa1f0…>
after last Thursday
- Implemented
<https://github.com/KantaraInitiative/wg-uma/commit/2521674d9f186f6b5676d29c…>
issue #251
- Quick cleanup of permission ticket language
Domenico has done some nice flowchart-y graphics around the notion of
"authorization process", "authorization interface", and the new token
landscape we can look at together tomorrow.
Let's see if we can get quorum, cement decisions around this direction, and
settle on set math decisions (what flexibility does the RS have? what are
the parameters within which the client works? how does this all work when
it's possible to register multiple resource sets when getting a permission
ticket?) tomorrow.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
