UMA telecon 2016-01-07
UMA telecon 2016-01-07
Date and Time
- Thu Jan 7, 9-10am PT
- Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines), room code 178-2540#
- Screen sharing: http://join.me/findthomas - NOTE: IGNORE the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line)
- UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar
Agenda
- Roll call
- Approve minutes of UMA telecon 2015-09-24, UMA telecon 2015-11-05, and UMA telecon 2015-12-17 if quorum
- Briefly review upcoming meeting schedule
- Recommendation ballot passed!
- Status of publication of Recommendations and IETF I-Ds
- Discuss candidate charter revisions and 2016 roadmap priorities based on proposed technical and legal efforts
- See notes from UMA telecon 2015-12-17 and list discussions for proposed technical efforts – summarizing:
- Use cases: IoT, API security (AS-RS tight), federated authorization (AS-RS loose), RS needs to apply mandatory access controls for higher "LOA", RO needs to preserve right of access, wide ecosystems, RO needs to ensure RS respects insufficient authorization data
- Technical issues: AAT burden, multi-resource-set permission registration, client-to-AS-first efficiency, validation of self-contained tokens
- Also see issue backlog
- Proposed legal efforts are to be discussed more fully on Friday, but we can review
- See notes from UMA telecon 2015-12-17 and list discussions for proposed technical efforts – summarizing:
- AOB
Minutes
Roll call
Quorum was reached.
Approve minutes of UMA telecon 2015-09-24, UMA telecon 2015-11-05, and UMA telecon 2015-12-17
MOTION: Andi moves, Thomas seconds: Approve minutes of UMA telecon 2015-09-24, UMA telecon 2015-11-05, and UMA telecon 2015-12-17. APPROVED by unanimous consent.
Briefly review upcoming meeting schedule
The Jan 21 WG meeting is canceled. The APAC-friendly fortnightly sync meetings have been rescheduled, starting in the last week of January. The legal subgroup will be discussing tomorrow whether to restart weekly meetings.
Recommendation ballot passed!
Status of publication of Recommendations and IETF I-Ds: We got about 25 Yes votes and no No votes – a healthy response. We're still working on publishing the new Recommendations.
Regarding the email about the workflow for creating new Recommendations and drafts, Maciej has a new suggestion: creating new GitHub branches. It's a relatively infrequent step, though, so it may be overkill. He'll write that suggestion up.
AI: Andi: We should do a Kantara blog post about the new Recommendations and maybe share how many issues were closed, the number of votes, etc.
AI: Thomas: Create two new I-Ds, changed to Informational, for UMA Core and OAuth RSR, that just have abstract, first intro paragraph, and second paragraph that normatively links to the respective final Kantara Recommendation.
Discuss candidate charter revisions and 2016 roadmap priorities based on proposed technical and legal efforts
- See notes from UMA telecon 2015-12-17 and list discussions for proposed technical efforts – summarizing:
- Use cases: IoT, API security (AS-RS tight), federated authorization (AS-RS loose), RS needs to apply mandatory access controls for higher "LOA", RO needs to preserve right of access (health context), wide ecosystems (health context), RO needs to ensure RS respects insufficient authorization data (health context/BLT dimensions)
- Technical issues: AAT burden, multi-resource-set permission registration, client-to-AS-first efficiency, self-contained token validation (SCTV!)
- Also see issue backlog
- Proposed legal efforts are to be discussed more fully on Friday, but we can review
Mike mentions token exchange of an RPT for an OIDC token. How do you bridge a client that has been granted access by an AS all the way to getting access to a UserInfo endpoint? The reason to do this is that the AS is in claims-gathering mode. This is the "wide ecosystem" use case/conundrum.
Mike had started to sketch out a design for getting rid of permission tickets, and they may keep both, but he concluded "it's not UMA". :-)
Other ideas that have come up in the consent receipt world: Extension endpoint for ingesting consent receipts (nicknamed "Shoebox" by Andrew Hughes). Adrian has advocated for an AS to add this type of endpoint. (It doesn't exist yet.)
An exploration of UMA wrt blockchain could be worthwhile, for those who have an interest. (An early exploration happened here.) OTOH, it could be a distraction if we're not careful. Thomas points to this provenance-tracking work that he did with Jim H. This is a novel use of UMA combined with agreements and blockchain: UMA-protected agreement deltas that can then be put on the chain, which are thus nonrepudiable, and available for public inspection and third-party auditing (and mediation?) in case of dispute long after the negotiation stage (this is where chain vs. digital signatures are a win).
AI: Eve: Present to the group next week a "matrix" that aligns use cases we've identified to date with technical "itches", for consideration as 2016 discussion topics for UMA post-V1.0.1 work. Don't tie us down to version numbers yet. We know we'll be working on the BLT spectrum.
Attendees
As of 18 Dec 2015, quorum is 6 of 11. (Evariste, François, Domenico, Sal, Thomas, Andi, Robert, Maciej, Eve, Søren, Mike)
- Eve
- Domenico
- Sal
- Mike
- Andi
- Thomas
- Maciej
- François
Non-voting participants:
- Katie
- Ishan
- Jin
- Jim Hazard