Child pages
  • UMA Roadmap for 2016

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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. The general #V2.0 label represents GitHub issues targeted for closure with the UMA V2.0 specs in early 2017.

If you are new interested to contribute to the Work Group and are interested to contribute to our work, see '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.

subgroup subgroup subgroup X 



  3552 (includes legal)

2 (includes legal

)

22 (includes legal)124
GitHub issues

use case
cases/
priorities

technical issue
issues/
proposals

#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
throttle access
beyond AS-imposed
limits

#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
information
sharing matters

153, 154AAT burden [DONE]X  X X  X 
153, 238OAuth token endpoint realignment [DONE] X  X  X 20, 154client-to-AS-first efficiency X      
51self-contained token validation [DONE]X         24, 224audit whether RS gave access
per permissions / "shoebox" endpoint
   XX X  X
95multiple-AS protection over a
single resource set
 XX   X   
152permission registration [DONE]          
157, 159discovery document alignment [DONE] X      X 
167, 205 (currently closed), 239 (now closed)

session fixation attack in

claims-gathering protocol and

similar [DONE]

       X  
155RSR endpoint URL has extraneous parts [DONE]        X 
158"scopes" is confusing in introspection response [DONE]        X 
165client can't specify scopes [DONE]        X 
167, 237simplify "need_info" and
claims-gathering endpoint provisioning [DONE]
        X 
254Hashed claims discovery [consider]          
260Cascading authorization servers[consider]  XXX     
24, 224audit whether RS gave access per permissions / "shoebox" endpoint [consider]   XX X  X
20, 154client-to-AS-first efficiency [keep in backlog] XX       
95multiple-AS protection over a single resource set [keep in backlog] XX   X