UMA telecon 2012-03-29

Owned by Former user (Deleted)
Last updated: Apr 06, 2012Version comment

UMA telecon 2012-03-29

Date and Time

(Please continue to check for summertime skew effects for the next few weeks!)

  • WG telecon on Thursday, 29 Mar 2012, at 9am PT (time chart)
    • Skype: +99051000000481
    • US: +1-805-309-2350 (other international dial-in lines available) | Room Code: 178-2540

Agenda

  • Roll call
    • Chair pro tem for Apr 12 telecon?
  • Approve minutes of 2012-03-08, 2012-03-15, and 2012-03-22 meetings
  • Tweet chat AIs and other outstanding AIs
    • April 25th okay for third tweet chat?
  • Review latest spec and figure out next batch of issues to resolve
  • Interop planning
  • AOB

Minutes

Roll call

Quorum was not reached.

Approve minutes of 2012-03-08, 2012-03-15, and 2012-03-22 meetings

Deferred due to lack of quorum.

Tweet chat AIs and other outstanding AIs

  • April 25th okay for third tweet chat?

Yes, let's make it happen! Same bat day/time/channel... Wed 9am PT/noon ET.

UMA branding question: We'll use "lazy evaluation" on this.

Business use cases: Eve will reach out to Trey regarding his comment on the tweet chat. We know that the topic of AS/RS separation, being discussed in the OAuth WG as well, is a key micro-use cases for enterprises. This also relates to dynamic registration (and discovery). Thomas has been following the IETF OAuth discussion through Jabber and audio. They spent their time talking primarily about the three current drafts and WG Last Call. There was a little time spent on the rechartering topic, during which John Bradley was very helpful in explaining the current state of play.

Dynamic registration: Folks on the OAuth list have expressed clear interest in starting with the draft we submitted. They will just need to know that there are editor cycles available.

AM widget idea: To be explored further. Check out the Backplane protocol for possibilities.

Review latest spec and figure out next batch of issues to resolve

In Sec 1.3, remove sentence fragment at end.

In Sec 3.4.4, reword "The endpoint MUST use SSL/TLS. This specification dictates the use of POST because it is advantageous for security in cases where the RPT is a bearer token. Since the requester provides its own authorization API token in the authorization header of the request, the RPT appears in the request body. A GET operation would expose the message to being recorded in AM access logs." to say:

"The endpoint MUST use SSL/TLS."

In the same section, add a request message example:

POST /token_status HTTP/1.1
Host: am.example.com
Authorization: Bearer DEADBEEF (change the gibberish so that it's clearly not a PAT or the same PAT - it's an AAT)
Content-Type: application/json
...

{
"rpt": "sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv",
"ticket": "016f84e8-f9b9-11e0-bd6f-0021cc6004de"
}

In Sec 3.1, add a request message example, so that we demonstrate what an RPT looks like and how it's identified (e.g. as "Bearer"). This will clarify that the RPT will be used just as if it were a standard OAuth bearer token.

In Sec 3.4.4, the new need_claims error seems to need some additional context. For example, how does the arrival of the redirected requesting party correlate to the permission ticket in question? George notes that it's dangerous to assume that if Roger shows up at the AM, willing to supply claims, it's associated with the permission ticket you think it is. Is it sufficient for the requester to send the user over with the permission ticket in question? It seems sufficiently secure and private to pass it in a query parameter. So...

In Sec 3.5.1, we need to add the requirement for the requester to construct the redirect URL with a parameter of ticket=foo so that the AM knows which claims to ask for. The AM will internally have to manage/adjust the time-to-live of the ticket if the requester actually shows up with it the first time and gets a need_claims response.

Do we have to specify the names of the query parameters in all cases? Some methods will be claims-profile-specific and some will be generic. We think the ticket one is generic.

In Sec 3.5.1.1, provide a concrete explanation/example of how OpenID Connect (already) specifies the redirect, callback, and state parameters etc. (or raise the issue that they don't standardize this, and then we can define a standard set of query parameter names where they're not already provided).

Something to think about: When is it time to make OpenID Connect be an MTI claim profile?

Eve will revise the spec lightly according to our consensus today (now DONE), and Thomas will publish the next draft as an I-D.

Interop planning

Let's do that for the next two weeks solid.

Upcoming F2F opportunities

In addition to Munich, we also have IIW May 2-3. George and Thomas are definitely planning to attend. Eve may be able to attend. We should plan to have a F2F.

Eve will reach out to the organizers and to Maciej to see who might be able to host a F2F meeting.

Next Meetings

  • WG telecon on Thursday, 5 Apr 2012, at 9am PT (time chart) – interop prep
  • WG telecon on Thursday, 12 Apr 2012, at 9am PT (time chart) – interop prep – Eve regrets; Maciej chair? (Thomas can if Maciej can't)
  • WG telecon on Thursday, 19 Apr 2012, at 9am PT (time chart)
  • WG telecon on Thursday, 26 Apr 2012, at 9am PT (time chart) – Eve regrets; Maciej chair?

Attendees

As of 24 Mar 2012, quorum is 6 of 10.

  1. Catalano, Domenico
  2. Fletcher, George
  3. Hardjono, Thomas
  4. Maler, Eve
  5. Moren, Lukasz

Regrets:

  • Szpot, Jacek
  • D'Agostino, Salvatore