UMA Roadmap for 2016
Having pushed its first major release (Version 1.0) and its first patch release (Version 1.0.1) out the door in 2015, in 2016 the UMA Work Group is has been examining developer, deployer, and user demand for improvements; the business and legal elements in the "access federation" equation; and implications of the newest trends, such as smart contracts, IoT, and blockchain.
Currently the WG is prioritizing its 2016 workload. The following draft matrix represents our analysis to datethe prioritized workload of the 2016 effort of the WG. The "hashtags" in the use-case column headers are labels in our GitHub issues list (#trust was the only existing one prior to 2016). How to understand this matrix: We will focus on use cases, and not assume that the GitHub issues currently associated with each use case are necessarily the only ones. As a random example, the "Internet of Things" as a use case currently is associated with one identified technical issue, but the use case may drive a variety of technical discussions that ultimately turn into design elements of an UMA V.next (or profile or extension specifications, or technical papers, etc.) beyond that one issue.If you are new to the Work Group and are interested to contribute to our work, see . The general #V2.0 label represents GitHub issues targeted for closure with the UMA V2.0 specs in early 2017.
If you are interested to contribute to the Work Group's efforts, we are happy to welcome you – see the wiki home page for information on joining as a participant. Topics under WG or subgroup discussion are shown along the top and down the left side in green. Topics that are likely to be left in the backlog and not taken up for V2.0 consideration are shown in gray.Note that we have a Legal Subgroup as well.
| 3 | 5 | 5 | 2 (includes legal | subgroup) | 2 (includes legal | subgroup) | 2 | 2 (includes legal | subgroup) | 1 | 2 | 4 | |||||||||||
| GitHub issues | use case technical issue | #IoT: IoT (constrained entities, offline entities, etc.) | #APIsec: API security (enterprise RO, AS-RS tight) | #fedauthz: federated authorization (enterprise RO, AS-RS loose) | #RSctrl: RS can | #ROctrl: RO can meaningfully throttle access that RS gives | #wideeco: wide ecosystem: RO's AS and RqP's IdP never met before, etc. | #trust: UMA model text for access federations and tools for building agreements and receipts | #security: fix security bugs | #simplify: simplify the protocol and make it work more like OAuth (thus includes feature addition too) | #shoebox: consent and notice and | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 153, 154 | AAT burden [DONE] | X | X | X | X | ||||||||||||||||||
| 153, 238 | OAuth token endpoint realignment [DONE] | X | X | X | 20, 154 | client-to-AS-first efficiencyX | X | ||||||||||||||||
| 51 | self-contained token validation [DONE] | X | 24, 224 | audit whether RS gave access per permissions / "shoebox" endpoint | X | X | X | X | |||||||||||||||
| 95 | multiple-AS protection over a single resource set | X | X | X | |||||||||||||||||||
| 152 | permission registration [DONE] | ||||||||||||||||||||||
| 157, 159 | discovery document alignment [DONE] | X | X | ||||||||||||||||||||
| 167, 205 (currently closed), 239 (now closed) | session fixation attack in | claims-gathering protocol and | similar [DONE] | X | |||||||||||||||||||
| 155 | RSR endpoint URL has extraneous | parts [DONE] | X | ||||||||||||||||||||
| 158 | "scopes" is confusing in introspection | response [DONE] | X | ||||||||||||||||||||
| 165 | client can't specify scopes [DONE] | X | |||||||||||||||||||||
| 167, 237 | simplify "need_info" and claims-gathering endpoint provisioning [DONE] | X | |||||||||||||||||||||
| 254 | Hashed claims discovery [consider] | ||||||||||||||||||||||
| 260 | Cascading authorization servers[consider] | X | X | X | |||||||||||||||||||
| 24, 224 | audit whether RS gave access per permissions / "shoebox" endpoint [consider] | X | X | X | X | ||||||||||||||||||
| 20, 154 | client-to-AS-first efficiency [keep in backlog] | X | X | ||||||||||||||||||||
| 95 | multiple-AS protection over a single resource set [keep in backlog] | X | X | X |