Versions Compared

Old Version 1

changes.mady.by.user Eve Maler

Saved on

compared with

New Version Current

changes.mady.by.user Eve Maler

Saved on

Key

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

...

Agenda

  • Roll call
  • Approve minutes of UMA telecon 2015-09-24 and UMA telecon 2015-11-05
  • Meeting schedule given holidays and absences for the rest of the year
    • No meetings Thu/Fri next week
    • No meeting Thu the following week due to Eve absence (and Fri unless we have a chair pro tem?)
    • No meetings Thu/Fri Christmas Eve/Day
    • No meetings Thu/Fri New Year's Eve/Day
  • Status of V1.0.1 process
    • LC ballot to certify Draft Recommendations
  • Public Review closure and approving Draft Recommendations for progression to LC for approval to start the KI All Member Ballot process
  • Independent Submission stance: any news/changes?
    • has passed
    • Kantara All-Member Ballot process can begin shortly after a few "metadata edits"; complete by end of 2015
  • Funding requests
  • IETF 94 news
  • Permission registration extension spec review How are we doing on other outstanding AIs?and discussion
  • AOB

Minutes

Roll call

Quorum was not reached.

Next week's calls

The WG call and the APAC sync are cancelled. The legal subgroup call will be run (and an agenda sent) by Adrian. Eve will "split the difference" with APAC-friendly calls and schedule one for two weeks from now vs. next week and three weeks from now.

Public Review and WG approval for LC certification as Draft Recommendations so that All Member Ballot can begin

Joni reports that we got a fair amount media attention, but no comments through the KI channel.

We got a couple of pull requests for minor typos (thanks, Sarah!) and Eve reported a few minor editorial issues and subsequently incorporated fixes for all but one. Maciej has generated drafts with all of that incorporated.

MOTION: Andi moves and Mike seconds: Approve the UMA Core V1.0.1 and OAuth RSR V1.0.1 specifications dated 5 Nov 2015, as amended with the agreed resolution to issue #229 and appropriate document metadata, for LC certification as Draft Recommendations so that All Member Ballot can begin. APPROVED by unanimous consent.

The Status section should say, instead of "...for Public Review", should say "for LC certification as a Draft Recommendation".

AI: Maciej: Edit the specs so we can turn them over to the LC to take up their e-ballot.

AI: Eve: Edit the Release Notes slightly to indicate the status change of the specs.

Independent Submission stance: any news/changes?

The discussion to gather more information is still ongoing.

Permission registration extension spec review

We discussed the configuration data situation.

Do we want to have an official UMA configuration data property that contains an array of profiles and extensions supported (by identifying URI)? Or instead – or in addition – does it make sense to have a property for each profile and extension (as this spec proposes) where the name is the identifying URI, and then you could provides all kinds of values, or even arrays etc., for finer-grained configuration of each profile and extension? George proposes something like this:

"extensions_support is a JSON map where the key name is the extension URI and the value is a JSON object defined by the extension"

This would ideally be something baked into the UMA spec. Does it make sense to do this in "the first extension produced by the UMA WG"? Also, the line between profiles and extensions is kind of thin. The spec, in Core Sec 1.4, explicitly stays out of the business of capturing profile or extension config data (at the end of the section). Should we get into the business?

We're thinking maybe not. The mere presence of the key might normally indicate that the AS supports the extension. However, in an ecosystem where there are multiple AS's, and some do support the extension and some don't, a random RS might want all AS's to explicitly declare the situation. So that's where a key of "identifying_URI" and a value of something like a Boolean could be used. If the extension in question wants to have the AS provide a complex set of parameters whenever they do support the extension, it would be ideal to allow the parser to be able to stop the moment it knows that the AS doesn't support the extension, vs. parsing a whole object. (Think token introspection.)

For our purposes here, we can keep it simple. Let's change to a Boolean for now.

AI: George: Write up a short UIG section capturing the above discussion on profile/extension config data. (Eve will send links and instructions.)

For the question about registration failure, George recommends for the AS to return an array of resource set IDs, each with a status, with an overall error.

Are we sure we want to return a single ticket for the set of requested permissions? The RS has always had complete discretion about what to register. However, since resource sets may have scopes that are totally distinct from each other, it may be very important – party for interoperability's sake – to explicitly register requested permissions for each resource set.

Note that the RS's registration of requested permissions is just about a bundling on behalf of the client. We don't get into authorization questions until the client actually conveys the ticket back to the AS to ask for authorization data at the RPT endpoint. So we're talking syntactic errors at this point.

We're agreed that if there's an error in the request, the whole request should fail. We seem to need more discussion about multiple requested permissions vs. one returned ticket; we know there would have to be a lot more infrastructure invented if we returned multiple tickets.

AI: Eve: Rev the permission registration extension spec.

IIW 21 roundup

Sorry there was no time to talk about IIW impressions! Do see the notes here (more still to come). There were lots of amazing discussions about UMA, and also consent receipts, and blockchain. (And don't miss Beyonce as a Service!)

Previous AI status

...

Approve minutes

tbs

Upcoming meetings

  • No meetings Thu/Fri next week (US Thanksgiving holiday)
  • No meeting Thu the following week (Thu Dec 3) due to Eve absence (Adrian can run Fri Dec 4 legal subgroup call)
  • No meetings Thu/Fri Christmas Eve/Day
  • No meetings Thu/Fri New Year's Eve/Day

Status of V1.0.1 process

  • LC ballot to certify Draft Recommendations has passed
  • Kantara All-Member Ballot process can begin shortly after a few "metadata edits"; complete by end of 2015

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

  • AI: Sal: Investigate IP implications of formal liaison activities with other Kantara groups with the LC, and ultimately draft an LC Note as warranted. [DONE]
  • AI: Gil: Edit the UIG to add Ishan's content and excerpt it for Eve to add to the FAQ, pointing everyone to the UIG.
  • AI: Mike: Write SCIM protection case study to highlight client claims-based use case.
  • AI: Andi and Zhanna: Please look at the section on optional and extension properties to see what might need an update to account for V1.0.1. [DONE]AI: Maciej: Review and correct the Redirecting the Requesting Party to the Client After Claims Gathering section.AI: Maciej: Write up some recommendations for the RPT Refreshing section.
  • AI: Maciej: Try to find Justin's old recommendations for the Permission Ticket Management section.

...

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. AndiMike
  3. Arlene
  4. ThomasMaciej
  5. Domenico
  6. MikeSal
  7. Maciej

Non-voting participants:

...

  • Sarah
  • Andrew J
  • Katie
  • George
  • John WJames
  • JinSarah

...

  • Scott
  • JoniAdrian