UMA telecon 2011-08-25

Owned by Former user (Deleted)
Last updated: Aug 25, 2011Version comment
4 min read

UMA telecon 2011-08-25

Date and Time

  • WG telecon on Thursday, 25 Aug 2011, at 9-10am PT (time chart)
    • Skype line "C": +9900827042954214
    • US: +1-201-793-9022 (other int'l numbers) | Room Code: 295-4214

Agenda

Attendees

As of 22 Aug 2011, quorum is 6 of 10.

  1. Catalano, Domenico
  2. Fletcher, George
  3. Hardjono, Thomas
  4. Maler, Eve
  5. Moren, Lukasz
  6. Morrow, Susan
  7. Wray, Frank

Non-voting participants:

  • Kirk Brown

Minutes

Roll call

Quorum was reached.

Approve minutes of 2011-08-11 and 2011-08-18 meetings

Minutes of 2011-08-11 and 2011-08-18 meetings APPROVED.

Action item review

  • 2010-11-18-4 Eve Open Capture new user stories in the wiki.
  • 2011-04-14-1 Maciej, Alam, Eve Open Build list of FAQs (both questions and candidate answers) on the wiki.
  • 2011-07-07-2 Thomas Now closed Capture all current issues, resolutions, and statuses in GitHub.
  • 2011-08-18-4 Susan, Eve Open Draft a Waterford Institute contest entry. In progress. Sal will help.
  • 2011-08-18-5 Lukasz Now closed Propose a simple error message for GitHub issue #4.

Plans for Sep and Oct identity gatherings, including UMA F2F in Redwood City, CA on Thursday afternoon, Oct 20

Maciej M. is able to represent UMA to discuss OpenID Connect/UMA integration issues at the Sep 12-13 OpenID "Connect Tech" summit.

Eve, Kirk, George, Lukasz, and possibly others will be available for the UMA F2F and IIW.

Be sure to register for events that you want to attend! Links are on the wiki.

Core protocol issues in GitHub

#1
Requester token missing in: 3.4. Host-AM: Register a Permission

The question is whether the host, in registering a permission, should include the token that the requester gave it, so that the AM can associate the requester's later incoming permission request with the permission. If the host chooses to register resource set IDs (embedded as part of this permission-registering interaction) that are very specific to this requester, e.g. making a resource set ID that's hashed with this requester, then supplying the requester's token in addition "oversupplies" requester-binding information. But if the host wants to manage resource set IDs generically, and doesn't pass along the requester's token, does the AM have enough information to proceed when the requester shows up? We think the requester's possession and presentation of the ticket is sufficient.

In fact, George points out that the permission ticket could even be reused among different requesters that approach! We need to be clear that the permission ticket needs to be unique per permission request. The ticket is an opaque blob, and it's up to the AM to dictate what it looks like. We want the permission binding to happen only when the requester goes to the AM. So we're not particularly concerned with requester impersonation, but rather with the ability to interoperate among the UMA parties in the circumstance where scopes and permissions have no standardized language (yet). A permission ticket serves as a reference to a private-language AM-host permission (resource set ID and set of scopes) that the requester can safely treat as a blob. The requester is still an untrusted party until it wins that permission and gets it associated with its token, and thus it has no right to see resource set IDs for privacy reasons alone.

Further, although the spec says the permission ticket should have an expiration time, currently the messaging doesn't contain this. Can this be left implicit and not passed around in the messages? If the requester shows up too late, with a valid token but an expired ticket, the AM should respond with an invalid request error.

Closed with instructions to the editor to:

  • Revise Section 3.4 to explain that the permission ticket is a short-lived handle, but remove the mention that the expiration time would be included in its response.
  • Add something to Section 3.5 (which we know still needs lots more work) to say that one of the AM's outputs to the requester is an error that indicates that the permission ticket expired. This could potentially be an "invalid token" with an explanation that gives more detail.

#2
Need to unify the request for authorization with the providing of claims, so that this can be a single request-response pattern that can loop as required

For the "excruciatingly simple" case, Lukasz has outlined SMARTAM's solution, which involves the requester literally redirecting requester operator to the AM, where an interface asks for self-asserted claims. Whenever you use a redirect, do you have to worry about correct binding of the "same party" during this handoff? Lukasz notes that the way SMARTAM binds this to the right requester is that the requester shows up with their requester token. Do we need a ticket for this flow?

Since by this point the requester has a token (issued by the AM), is it possible that the AM already knows some claims about that requesting party?

And what if the requester shows up asking for multiple permissions at once? This somewhat relates to new issue #20.

This is not closed yet.

(#3 was closed.)

#4
If the content-type is not recognized by the AM, what happens then?
(Lukasz has done his action item; we'll discuss next time.)

#5
What happens when a resource (being registered) already exists?
(This is just about ready to be closed; we need to be sure that the editor instructions are clear. Next time.)

#6
Can Update Resource Set Description API mistakenly overwrite/destroy an existing resource description?
(I believe this essentially duplicates #5, so hopefully we can officially close both. Next time.)

#7
Is it OK to cache token status (as now explained)?
(Paul has made concrete suggestions that we might want to adopt. Next time.)

Next Meetings

Note: Meetings are now 60 minutes in length.

  • WG telecon on Thursday, 1 Sep 2011, at 9-10am PT (time chart)
  • WG telecon on Thursday, 8 Sep 2011, at 9-10am PT (time chart)
  • WG telecon on Thursday, 15 Sep 2011, at 9-10am PT (time chart)
  • WG telecon on Thursday, 22 Sep 2011, at 9-10am PT (time chart)
  • WG telecon on Thursday, 29 Sep 2011, at 9-10am PT (time chart)