http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-11-19

Minutes

Roll call

Quorum was not reached.

Approve minutes

tbs

Upcoming meetings

Status of V1.0.1 process

Maciej has made the required edits to the specs' metadata to ready them for All-Member Ballot. So now it's up to Oliver and Jane. Incidentally, the XSLT stylesheet now handles everything automatically rather than requiring manual tweaking. This means that other WGs could be using it too!

AI: Maciej: Alert Jane Celusak that the stylesheet could be used as a tool by other WGs.

Funding requests

The main purpose of the UMA Dev WG is really seeding the ecosystem, not interop testing. And the interop test GUI he developed is separable. And Roland hasn't done much development since he started refactoring.

Does this mean the job properly devolves to this group? On the other hand, software – especially if we want to ensure that it remains FOSS – does nicely go hand in hand with the Dev group.

The UMA group is still working pretty hard on features and such, so spending time overseeing software development may overwhelm us.

So maybe software should stick with software, and interop testing is a natural function of encouraging wide ecosystems as long as testing is made very easy.

Resource servers are a policy enforcement point, so it's very important to know that they're getting it right. Adrian's new HIE of One project deals with this by saying "Here's a very simple implementation of an authorization server that can be given away (and used by a single individual)." The RO would have to do no setup; it's a "personal data store" kind of use case. Each of the existing open-source authorization servers is optimized for different use cases: API security vs. individuals, individual scale vs. whole consumer populations...

AI: Eve: Report back to Jane that this WG won't be spending our budget allotment in 2015, and we're withdrawing the request.

(She'll bring up the idea of doing a 2016 funding request through the UMA Dev WG.)

IETF 94 news

It appears there's now interest in RSR, or something like it, in OAuth now that they're rechartering. Would a general service metadata endpoint be a good idea in addition to registering the stuff that needs to be protected? Could the OTTO work be added to the mix?

What are our thoughts on next steps?

Mike advocates for moving everything (Core and RSR) to IETF. Eve advocates for being tactical and only working to explore "sedimenting" RSR into IETF right now. George is not in favor of moving Core. Maciej seconds George. Sal too – he notes that this could be a diversion. It's important to move ahead with deployments and use cases and proving the value. Mike's rationale: Adoption is what matters; Core could be very useful to enable a federation standard where UMA is the access token for identity information – then UMA would become a federated identity protocol. Mike feels that if we don't "move both", we shouldn't even "move RSR"! More to come on this subject. (See the Skype chat for more.)

AI: All who are able and willing: Track IETF OAuth conversations about OAuth/UMA/API security more closely.

Permission registration extension spec

Deferred.

Previous AI status

Attendees

As of 13 Oct 2015, quorum is 7 of 13. (François, Domenico, Sal, Thomas, Andi, Mary, Robert, Maciej, Eve, Sourav, Lisa, Arlene, Mike)

  1. Eve
  2. Mike
  3. Maciej
  4. Domenico
  5. Sal

Non-voting participants:



Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com