https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-06.html#am-endpoints
We decided in yesterday's call to remove the following properties entirely:
*pat_profiles_supported*: TO BE REMOVED in rev 07
*rpt_profiles_supported*: TO BE REMOVED in rev 07
We agreed to discuss what to do about the others, on the principle that
defining extensibility points when there's only a single exemplar of a
usage of the extensibility point is not a good enough rationale for it.
*pat_grant_types_supported*: REMOVE OR KEEP?
The OAuth Metadata spec
<https://tools.ietf.org/html/draft-ietf-oauth-discovery-04#section-2> defines
an optional grant_types_supported property. We could say that since a PAT
is an ordinary OAuth access token, an UMA AS could simply leverage OAuth AS
metadata in the usual way and use this property if it wants to (or not say
anything at all, since a PAT is 100% purebred OAuth).
*Proposal*: Remove.
*claim_token_profiles_supported*: REMOVE OR KEEP?
This ties to Sec 3.6.1
<https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-06.html#claim-push>.
We don't define any claim token profiles ourselves, but -- perhaps
dangerously -- provide an example of a format called "
http://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken", by
which we loosely meant OIDC built-in plus extension claims. I know several
UMA implementations have included this, but I have no idea if they're
interoperable.
*Proposal*: Keep, but seriously clean up the language around HybridIDToken,
and possibly supply a couple of real profiles for the obvious ID tokens
people would want (canvass implementers for interest in which kinds of
tokens).
*uma_profiles_supported*: REMOVE OR KEEP?
This ties to both Sec 5
<https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-06.html#comms-profil…>
(*extensibility* profiles already defined in the spec, with the intention
that various communities would hopefully define *extension* profiles on top
of them) and Sec 6 (UMA's framework for third parties to build profiles and
extensions, based on SAML's similar one). Since the AS has config data, and
right now the RS and client don't really (I guess there's software
statements too), there's a bit of a hole regarding what profiles and
extensions can formally be expressed.
*Proposal*: Keep. Canvass implementers for interest in the extensibility
profiles. Ensure that Sec 6 fully includes extensions as well as profiles
in its language. Consider whether there's anything to say about software
statements, and anything forward-looking to add about other "authorization
metadata/config framework" efforts going on.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
(The legal subgroup is meeting tomorrow as usual; I just sent out the
agenda.)
NEXT WEEK:
The WG is MEETING AS USUAL on Thu Nov 10.
Sorry I didn't mention this on today's call, but I needed to CANCEL the
legal subgroup meeting for Fri Nov 11.
WEEK OF NOV 14:
Our Thu Nov 17 WG meeting is MOVED to 9am PT (usual hour) Fri Nov 18.
The legal subgroup is meeting as usual on Fri Nov 18 at 8am (just before
the moved WG meeting).
WEEK OF NOV 21:
The WG is NOT MEETING Thu Nov 24 and the legal subgroup is NOT MEETING Fri
Nov 25 because of the US Thanksgiving holiday.
I've just made these changes in the online calendar
<http://kantarainitiative.org/confluence/display/uma/Calendar>. If you're
not already subscribed, it's a good idea to do so.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-11-03
MinutesRoll call
Quorum was reached.
Logistics
*We're ON for Thu Nov 10* – regrets from Justin, Andi is unsure.
We need to *MOVE our Thu Nov 17 meeting to 9am (usual hour) Fri Nov 18* –
regrets from Cigdem, Domenico.
We're *NOT MEETING Thu Nov 24 or Fri Nov 25* because of the US Thanksgiving
holiday.
Approve minutes
Approve minutes of UMA telecon 2016-10-13
<http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-13>:
Deferred.
Work on UMA.next issues
"Authorization process": The definition could potentially be improved by
breaking the first sentence into two. The second sentence could focus on
risk management. Can we define "trust" formally somehow as managing risk?
Do we need "trust elevation" anymore? This is a live thread in email. Is
the equation "The RO only authorizes access within their risk
appetite/tolerance"? Maybe this is where we could point off to the UMA
Legal work because it's a complex equation and the RO isn't the only party
with risk and liability. Robert notes that part of decision is how you make
a good decision. A technical spec's job isn't to describe *all* of this,
but it could point off to other resources that go into it.
"Authorization process: The process through which the client obtains an RPT
from the authorization server in order to access a protected resource. The
process has two activities, and these can iterate. One activity is
assessing claims and other contextual factors against the resource owner's
policy conditions. Another is is collecting claims, which can include both
claims pushed from a client and interactively gathered from a requesting
party.
Suggestion to Domenico for his new flowchart: Try switching input and actor
bands, and adding an actor so there's always two. Let's be sure that it's
"technically accurate" as much as possible, assuming developers will take
it seriously. Andi suggests it will be used more "generically", so maybe we
can use it more at a 50K foot level.
Regarding "token profiling goes poof": Medication/read 22354546 read
Regarding the "*supported" options in the config data: Both Justin's and
Cigdem's implementations implement and ignore them! Is there any dissent to
pulling pat_profiles_supported and rpt_profiles_supported?
Instructions:
- Sec 3.5.4: "The fifth error response, need_info, begins *or continues*
..."
- Redefine "authorization process" through as two activities/states, and
be sure to incorporate "client identity" and any other contextual factors
(we used to call this "RqP-independent").
- Undo the "token profiling goes poof" and reconstitute the actual
introspection response part; make use of 7662 mandatory.
- Remove pat_profiles_supported and rpt_profiles_supported
*AI:* Eve: Send separate email threads about all the other "*supported"
config data fields and rationales pro and con.
Attendees
As of 3 Oct 2016, quorum is 6 of 11. (Domenico, Sal, Nagesh, Andi, Robert,
Maciej, Eve, Jeffrey, Mike, Cigdem, Sarah)
1. Domenico
2. Nagesh
3. Andi
4. Robert
5. Maciej
6. Eve
7. Cigdem
8. Sarah
Non-voting participants:
- Justin
- Francois
- Kathleen
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
What this means for our call times this week, since US Pacific is normative
for us, is that the WG and legal calls will be one hour earlier than usual
for those in the UK and Europe. The "summertime skew" should right itself
next week.
If you have any questions, subscribing to the online calendar
<http://kantarainitiative.org/confluence/display/uma/Calendar> should
answer them.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Completing my action item. Please let me know what you think!
Current mission statement(s)
<http://kantarainitiative.org/confluence/display/uma/UMA+Legal>
Recent discussion on this point
<http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note…>
- Produce a set of toolkits and associated educational materials by the
end of 2017 whose purpose is to accelerate the ability of those in the
following roles to adopt, deploy, and use UMA-enabled services in a manner
consistent with UMA's charter
<http://kantarainitiative.org/confluence/display/uma/Charter>*,
particularly where the resource owner is an individual:
- Individuals themselves ("natural persons")
- Organizations ("legal persons" such as businesses and governments)
- Legal representatives of the above
- Focus on GDPR-related toolkits first and foremost. A toolkit could
be anything that helps use or leverage an existing piece of legislation or
framework, such as an SDK, a checklist, consent receipt templates or
profiles, or a set of CommonAccord text, and could be related to the GDPR
itself, the EU-U.S. Privacy Shield, BCRs, and so on.
- Develop a roadmap by the end of 2016 that identifies specific
deliverables and timelines within 2017.
- By the end of 2016, develop two initial deliverables to inform the
roadmap work:
- Comparative analysis of UMA and GDPR concepts such as data subject,
processor, and controller
- Roundup of contractual and regulatory use cases
- Leverage specialist legal expertise wherever possible to complete and
review the deliverables.
*What I mean here, specifically, is: "enable a resource owner to control
the authorization of data sharing and other protected-resource access made
between online services on the owner’s behalf or with the owner’s
authorization by an autonomous requesting party"
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note…
2016-10-28
- Working session on User-Managed Access (UMA) in Contractual and
Regulatory Contexts
<https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…>
- Working through use cases per party in the transaction
Attending: Eve, Jeff S, Kathleen
*Parking lot*
A FAQ would be: What about the identity story? What about where the
identity of the RO would be stored vs where the consents would be stored?
(thinking of Eve's "scenario 1", which is the UK Blue Badge one)
*FAQ idea*
We should add FAQs in the doc itself, to answer questions right as they
arise in readers' minds, such as:
- Once data is unshared, doesn't the recipient already have the data?
What happens after that?
- This model seems to assume that the enterprise doesn't have any
overarching policy itself, and just allows a user to have any sharing
policy they wish. Is that correct?
- This relates to the larger topic of moving the setting on the
continuum of org/individual control more towards the individual; see
"blockchain identity use case"
- What are specific burdens around PHI vs generic PII?
Let's collect these and be as "pointed" as possible in formulating them. We
can decide how and where to answer them as we go.
*Funded legal analysis and use case work*
Eve reached out to Karsten, who likely doesn't have time for the work
himself, but who has kindly made himself available to chat with Eve to
suggest next steps. She will take action on this.
Eve suggests that we should decide, by the end of the year, which
deliverables to produce in 2017 as "toolkits" (of some sort) for *all* of
the frameworks out there. We discussed our rationale for this: It's to get
from our very early stage of UMA adoption to exactly one evolutionary stage
further. [image: (smile)] Meaning, we recognize that organizations have
incentives to gather data, sometimes act badly towards less-empowered
parties (individuals in the main), and so on, and we are looking to
demonstrate benefits to those organizations – particularly business and
legal audiences -- of the use of UMA through educational materials and
reduce friction in using UMA through our "toolkits" (which could be model
clauses, could be BCR tools, could be consent receipt templates or
profiles, etc.).
This is basically a further sharpened mission proposal, if you compare to
our 2015 and 2016 versions
<http://kantarainitiative.org/confluence/display/uma/UMA+Legal>.
*AI:* Eve: Propose a sharpened mission statement on the list for review.
Regarding the number of use cases in the world: The hope is that it's more
like prepositions (a couple of dozen in English) vs verbs (essentially
infinite)! But if there are really any number of them, probably we'll have
to identify the most common ones that have lots of examples that hew to a
pattern, and leave the "long tail" ones alone. Eve is planning to document
these briefly in the wiki and prepare them for our hoped-for legal expert
to review, so that we can get to a place where our "toolkits" can supply
good tools that map neatly to GDPR interpretations.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
