UMA telecon 2016-01-07
...
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.
...
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.sdf
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