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
  • Minutes approval
  • Report on All-Member Ballot plans
  • Report on ACE discussions
  • Review upcoming F2F opportunities
  • Binding Obligations: time to reinvigorate?
  • Next steps and other outstanding AIs
  • AOB

Minutes

Roll call

tbsQuorum was not reached.

Minutes approval

tbsDeferred.

Report on All-Member Ballot plans

tbs

...

The Ballot has begun! Colin also offers help in addition to our other list.

Report on ACE discussions

 

tbs

...

Review upcoming F2F opportunities

tbs

Next steps and other outstanding AIs

AI: Eve: Do this.

  • Help straightening out the repo once and for all

Eve has some past history of the spec revs. Should we capture this, or not? The IETF I-D versions are a coarse-grained method captured in XML form, and they can even show us diffs on the IETF site. So we can just push the current XML state to the repo and not worry about it. However, Eve would like to fix this problem in future. (smile) Apparently http://www.sourcetreeapp.com/ is favored, or a command line. People also mention https://mac.github.com.

Do a tweet chat or series? The idea is that it's about UMA and its current state, maybe for a developer audience. Too early for that? Mike thinks having a showcase application first is better. Maybe then for architects?

The RSA crowdsourced session submissions close very soon! After this, it will be time to GOTV for those too.

For CIS, we think UMA will get covered somehow, either by Eve if she can attend, or hopefully by someone she nominates.

AI: Eve: Put in an issue to make an editorial correction to the example in RSR Sec 2.3.3 to change it to 200 OK from 204 No ContentEve has been discussing a door lock use case with Hannes T and Erik W of the ACE group, and they're all working on an I-D to be considered at IETF 92. Maybe we can publish the case study on the UMA site as well; Mike has another blog post on such a subject too, and he may be able to attend the IETF meeting. Eve will see if Marcelo can attend IIW, since she and Hannes will also be there and hope to discuss this in a group setting there as well.

Sal described how attacking a pairing code is a way to hack low-power.

Mike poses the question: What's the user interface for the person approaching the door? Gil proposes: Facial recognition. Sal proposes: You break out your "key". Mike proposes: The door has a URL! Thomas proposes: Scratch on the door. (smile)

AI: Eve: Ask to get Sal access to Hannes/Erik document as well.

Review upcoming F2F opportunities

We updated the list on the Meetings and Minutes page.

Next steps and other outstanding AIs

 

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.

Outstanding AIs:

  • AI: Sal: Fill out IDESG form.
  • AI: Eve: Add IP health warning header to GitHub.
    • Done, thanks to Thomas and Maciej.
    AI: Eve: Put in an issue to make an editorial correction to the example in RSR Sec 2.3.3 to change it to 200 OK from 204 No Content.
    • Done.
    AI: Eve: Edit UIG (Mike's input, Zhanna/Andi's input)
  • AI: Maciej: Write as many sections for the UIG as he can. (smile)
    • This is under way.
  • AI: Eve: Send suggested updates to Will at Gluu for English page updating, and to Domenico for Italian page updating, and to Rainer for hoped-for German page updating, and to Riccardo Abeti for the Spanish page, and to Mark for a Dutch translation.
    • Pending.
  • AI: Ishan: Review the FAQ for needed updates (http://tinyurl.com/umafaq).
    • Suggestions sent – review together?
    • We reviewed it and love it! We want to publish it immediately.
  • AI: Robert: Noodle on the kitten metaphor.
    • He's working on a Justice project with lots of access control use cases. He's still thinking about the "simple story" slides.

We discussed Mike's V1 text on:

Organizations as Resource Owners and Requesting Parties


It is common for one domain to call an API in another domain. Sometimes a person is behind this call. But other times, the API may represent an organizational business process. For example, consider a business analytics engine calling an API to gather data, machine-to-machine communication or autonomous web service clients.


In these cases, an UMA Authorization Server can may use a number of different pieces of data to make a decision to grant access. In higher education multi-party SAML federation, attributes are used to group certain websites, for example as “research.” A similar idea can be applied to UMA clients, where a domain might use the client id, or previously registered information about the client to make an access decision. Of course, network address, cryptographic keys, geolocation of the originating request, time of day, the results of fraud detection services, and other mechanisms may be used.

We're thinking there's room for revision. Eve suggests defining an example where there's a non-human resource owner, and then explaining implementer implications (client credentials for PAT, no "consent", etc.), and then an example where there's a non-human requesting party, and then explaining implementer implications (client credentials for AAT, no "redirect_user" oppoprtunities, etc.). Are the two just additive, or is it something more?

What about "client claims"? Where might these come from? Software statement? It's up to the AS to get these from somewhere.

Attendees

As of 13 Feb 2015, quorum is 7 of 13. (Dom, Sal, Mark, Thomas, Andrew, Robert, Maciej, Eve, Mike, Jin, Ishan, Ravi, John)

  1. Eve
  2. tbsMike
  3. Maciej

Non-voting participants:

  • Gil
  • tbsColin
  • Zhanna