UMA telecon 2010-06-10

Owned by Former user (Deleted)
Last updated: Jun 11, 2010Version comment

UMA telecon 2010-06-10

Date and Time

  • Thursday, 10 Jun 2010 at 9:00am-10:30am PT (time chart)
    • Skype: +9900827042954214
    • US: +1-201-793-9022 | Room Code: 295-4214

Agenda

  • Administrative
  • Step 1 review (continued)
  • Claims trust model review
  • OpenID/AB review
  • AOB

Attendees

As of 3 Jun 2010 (pre-meeting), quorum is 6 of 11.

  1. Adams, Trent
  2. Fletcher, George
  3. Gamby, Randall
  4. Holodnik, Tom
  5. Machulak, Maciej
  6. Moren, Lukasz
  7. Scholz, Christian

Non-voting participants:

  • Gerry Gebel
  • Joe Andrieu
  • Mark Lizar

Guests:

  • Anna Ticktin (staff)

Apologies:

  • Catalano, Domenico
  • Maler, Eve

Minutes

Roll call

Quorum was reached.

Approve minutes of 2010-06-03 meeting

Minutes of 2010-06-03 meeting APPROVED.

Action item review

  • 2009-12-03-4 Eve Open Add terms-negotiation scenarios to Scenarios document.
  • 2010-03-10-6 Joe Open Revise the protected inbox scenario for next week's call.
  • 2010-05-13-3 Christian Open Spec out a "requester metadata" flow. Still open.
  • 2010-05-27-3 Eve Open Find and distribute info on the new proposal for OAuth signing.
  • 2010-05-27-4 Eve Pending Ask Dave Crocker for help with Step 1 user stories.

Nominations for the Specification Editor role

Christian nominates himself for the Specification Editor role but suggests that he may resign if it takes too much of his time.
Motion to undertake a non-secret ballot for the spec editor roll position - moved by Randall Gamby, seconded by Trent Adams — NO OBJECTIONS.
Motion to install Christian Scholz as the UMA WG leading spec editor. Seconded by Randall Gamby — APPROVED by UNANIMOUS consent.

Step 1 review continued

Christian discuss his progress on Step 1. The client credentials for the Host must be obtained before the OAuth flow can happen. Christian proposes that dynamic registration could be moved to a separate specification.
The client registration endpoint on the AM/AS side is where the client can register itself with the AM/AS. Discovery of the client registration endpoint happens through hostmeta (this endpoint is within the hostmeta XRD document). Christian suggests that we need to look at the current manual registration mechanisms for OAuth and use a similar approach for the automatic registration (in terms of data that needs to be exchanged).

For now, the Host uses a client descriptor (JSON document). Name and url key/value pairs are required while the rest is optional. The AM/AS replies with client credentials containing the client_id and client_secret (both OAuth related). For UMA, this document would also contain the resource registration endpoint. Christian discusses whether the structure of the latter should be flat or whether it should require an UMA-related namespace.

George asks if OpenID connect dynamic association can be used for this purpose and Christian refers to last week's conversation when this topic was discussed.

The issue of separate registration URIs for different hosts is then discussed. The resource registration URI can be either separate or can be global and OAuth protected (clients would be distinguished based on their access tokens). George says that there's not a huge difference programming wise. It might be slightly easier if URLs are separate for different clients.

Christian will email to IETF OAuth mailing list about client_id/client_name. Client_name would be used to display information about the client while the client_id would be optional.

Tom H. says that some people suggest using URLs as client_id. Discussion about using additional information in hostmeta about the client. The AM/AS can perform discovery on the client_id (if it's a URL). This is easy but would work only for the web server flow.

George mentions that client_id should be generated by the AM. Otherwise collisions are probable. Moreover, clients should not be able to impersonate themselves. Client_id should be always issued by the AM either with manual registration or dynamic registration. It would be the AM to manage collisions.

Impersonating is still possible (a client calling AM with a different name). This could be mitigated with providing a URL from which AM can retrieve some information (signed XRD discovery) and present them to the User. There might be some usability issues.

We agree that there is a potential need to move registration to a separate document. Christian proposes to discuss that with the OAuth community.

Christian will continue to work on his action item. As the specification editor, he will put the specification on bitbucket (for versioning) and prepare a proper RFC style. Anna will check if there are any IPR issues and if this can be done.

We defer discussion on the "Claims trust model" and "OpenID/AB".

Next Meeting

  • UMA WG telecon on Thursday, 17 Jun 2010 at 9-10:30am PT (time chart)
    • Skype: +9900827042954214
    • US: +1-201-793-9022 | Room Code: 295-4214

See the UMA calendar for details of future meetings.