UMA telecon 2014-10-09

Owned by Eve Maler
Last updated: Oct 09, 2014

UMA telecon 2014-10-09

Date and Time

Agenda

  • Roll call
  • Minutes approval if quorum
    • Sample motion: Approve the minutes of the last quorate telecon and read into today's minutes all the notes from all intervening non-quorate telecons.
  • Interop testing status
    • Testing has begun – just "config" and "dynreg" tests so far, with solutions figured out to enable "pat", "aat", "protapi", "authzapi", and "access" tests in future
    • Weekly meetings on Mondays at least through IIW
  • Meeting schedule review
    • Appears below and in online calendar – note well and RSVP to agendas!
    • V0.9 interop testing in Oct
    • IIW Oct 28-30 with open implementors' meeting Oct 29
    • V1.0 editing – when exactly?
    • Interop testing in rest of Q4 (V0.9->V1.0 switchover?)
    • V1.0 public review ~Jan 6-Feb 20; handle reported issues and declarations in real time
    • LC vote for KI Draft Recommendation status on Feb 25 if possible
    • KI All-Member Ballot Mar 2-16 if possible
    • V1.0 KI Recommendation status (and fresh IETF contributions?) late Mar if possible
  • FT-impacting issues on V1.0 docket: close in today's call if possible!
    • Eager permission registration issues (88 and 99)
    • 92: trust elevation profile
    • 105: status parameter in resource reg
    • 94: start_at for permission validity
    • 84: UMA endpoint names vs. OAuth endpoint names
  • AOB

Minutes

Roll call

Quorum was reached.

Minutes approval if quorum

  • Sample motion: Approve the minutes of the last quorate telecon and read into today's minutes all the notes from all intervening non-quorate telecons.

MOTION: Andi moves: Approve the minutes of UMA telecon 2014-08-28 and read into today's minutes all the notes from all intervening non-quorate telecons. APPROVED by unanimous consent.

Interop testing status

  • Testing has begun – just "config" and "dynreg" tests so far, with solutions figured out to enable "pat", "aat", "protapi", "authzapi", and "access" tests in future
  • Weekly meetings on Mondays at least through IIW

We have invented a method of solving for "token authentication" of ROs and RqPs. Roland reports that he already supports token authentication, so we should be good to proceed. It would be great to start reporting results in the wiki before IIW.

Meeting schedule review

  • Appears below and in online calendar – note well and RSVP to agendas!
  • V0.9 interop testing in Oct
  • IIW Oct 28-30 with open implementors' meeting Oct 29
  • V1.0 editing – when exactly?
  • Interop testing in rest of Q4 (V0.9->V1.0 switchover?)
  • V1.0 public review ~Jan 6-Feb 20; handle reported issues and declarations in real time
  • LC vote for KI Draft Recommendation status on Feb 25 if possible
  • KI All-Member Ballot Mar 2-16 if possible
  • V1.0 KI Recommendation status (and fresh IETF contributions?) late Mar if possible

Mark D is giving a lightning talk on UMA at Nordic APIs in a couple of weeks. Andi is giving a talk on UMA in Copenhagen in December as well. Sebastian Rohr is giving an UMA talk in German and we hope he'll offer his slides back for sharing. Eve was invited to speak on UMA at APIdays in Paris in December, but can't.

Mike suggests trying to have supplementary APAC-friendly times to meet, particularly if we can entice Nat to join those calls. This would be great but depends on Nat confirming attendance, which is difficult. So for now we'll proceed with the plan shown below.

FT-impacting issues on V1.0 docket: close in today's call if possible!

  • Eager permission registration issues (88 and 99)

Eve's proposal lets the AS have a lot of implementation-based control over RPT management. Maciej notes that returning 201 - Created isn't really right if the RPT isn't a new one. This relates to the questions Eve poses about what to do if the client puts the "wrong" RPT in the request for authorization data, or an invalid one, or whatever. We actually already have that problem in the current version of the spec – it says it responds with 201, but it doesn't mandate the creation and return of a new RPT.

The client shouldn't be "in control of" a true RPT resource at the AS the way an RS is truly in control of a registered resource at the AS, so we don't want to get into POST vs. PUT vs. whatever. It's just asking for authorization to access something. The AS should be able to manage authorization data and RPTs however it wants. Therefore, some kind of vague success response is all that's required. Would 200 - OK do? Or 204 - No Content in the case of keeping the same RPT or 201 - Created in the case of a new one? We think it should be defined.

Then the only thing we're missing is if the client sends an invalid RPT to the AS. Do we need to add an invalid_rpt error code? Since a good AAT along with a good ticket could still let the AS issue a new good RPT, maybe all that's required in this case is simply some "advice" that the RPT supplied wasn't good. How could we provide a warning, vs. an error that the provided RPT in the request was "not good", and either was invalid as presented or was revoked by the AS upon presentation? For example:

HTTP/1.1 201 Created
Content-Type: application/json

{
"rpt": "sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv",
"warning":"RPT in request was invalid."

}

Mark thinks an error response is better than this. Maciej agrees. People comment that it feels wrong to silently accept a wrong RPT over and over. So do we invent a new error code?

We did agree that the error code not_authorized_permission is okay to change to not_authorized.

  • 92: trust elevation profile
  • 105: status parameter in resource reg
  • 94: start_at for permission validity
  • 84: UMA endpoint names vs. OAuth endpoint names

Deferred!

Attendees

As of 2 Oct 2014, quorum is 8 of 14.

  1. Eve
  2. Mark
  3. Maciej
  4. Andi
  5. Thomas
  6. Jin
  7. Yuriy
  8. Sal
  9. Domenico
  10. Mike

Non-voting participants:

  • Zhanna
  • Marcelo
  • Adrian
  • Ann

Next Meetings

We will hold all-hands meetings (calling the roll) through the fall and early winter as much as possible; voting participants please attend! You can subscribe to the UMA calendar (and ask the chair to send you an event invitation) to see the times in your local time zone. Keep in mind that when the clocks change, we experience "summertime skew"; our home time zone is Pacific so non-US meeting times may shift.

  • Thu Oct 16 9-10am PT
  • Thu Oct 23 9-10am PT
  • (Clocks change in Europe on Oct 26)
  • No meeting Thu Oct 30 because of IIW – we are holding an open UMA implementors' meeting on Oct 29 at IIW instead
  • (Clocks change in US and Canada Nov 2)
  • No meeting Nov 6 (Eve regrets)
  • Thu Nov 13 9-10am PT
  • Thu Nov 20 9-10am PT
  • No meeting Thu Nov 27 because of Thanksgiving holiday in the US
  • Thu Dec 4 9-10am PT (change from APAC-friendly time)
  • Thu Dec 11 9-10am PT
  • Thu Dec 18 9-10am PT
  • No meeting Thu Dec 25 because of Christmas holiday
  • No meeting Thu Jan 1 because of New Year's Day holiday

Â