UMA telecon 2011-07-07

Owned by Former user (Deleted)
Last updated: Jul 07, 2011Version comment
7 min read

UMA telecon 2011-07-07

Date and Time

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

Agenda

  • Roll call
  • Approve minutes of 2011-06-30 meeting
  • Action item review
  • Balloting of spec as Draft Recommendation
  • Review of publicity efforts
    • Confirm action items and timeline
    • Coverage of/presentation at IETF meeting?
  • Dry-run and webinar planning
    • Hold meeting on Thursday Jul 14, or cancel?
  • Core protocol review
  • AOB

Attendees

As of 2 Jun 2011 (pre-mtg), quorum is 6 of 11.

  1. Catalano, Domenico
  2. D'Agostino, Salvatore
  3. Fletcher, George
  4. Hardjono, Thomas
  5. Maler, Eve
  6. Morrow, Susan
  7. Wolniak, Maciej
  8. Wray, Frank

Non-voting:

  • John Bradley
  • Rainer Hoerbe
  • Mark Lizar

Minutes

New AI summary

  • AI: John: Advise on how to make Claims 2.0 JWT-friendly.
  • AI: Thomas: Capture all current issues, resolutions, and statuses on the UMA wiki.
  • AI: Eve: Ask Paul Bryan for advice on Issues #25, #27, #37, and #38.
  • AI: Maciej M. and Lukasz: Examine issue #38 and propose a solution.

Roll call

Quorum was reached.

Approve minutes of 2011-06-30 meeting

Minutes of 2011-06-30 meeting APPROVED.

Balloting of spec as Draft Recommendation

MOTION: Moved by George, seconded by Frank: Approve Rev 00 of the UMA core spec as a Draft Recommendation. APPROVED by unanimous consent.

Review of publicity efforts

We now have a Facebook page! And we've had enough "likes" to get a nice URL. Please encourage "likes", and blog, tweet, and FB our upcoming news, using the hashtag #UMAWG.

Domenico suggested that we may want to start a Wikipedia page. John notes that having lots of citations is important for establishing the bona fides of the content, and it should be neutrally presented. We will keep this idea on the back burner, and see if someone drawn to UMA by our news may be interested to do this. Rainer has a lot of Wikipedia knowledge. Susan mentions that there are other venues where similar entries might be useful. Go for it!

Which wiki content is "not ready for prime time" yet? Probably just the FAQ at this point; we should strive to add more to it.

Who will be at the IETF 81 meeting? Thomas and John will be there, and will attend the OAuth portions. Eve will follow up with Hannes, mentioning our availability and desire to present on the UMA I-D there.

Please register for the webinar on Wednesday! Susan, Thomas, and Domenico are planning to attend.

Upcoming meeting schedule

We will cancel our regular telecon meeting on the 14th.

Core protocol review

See the current issues list and prioritization.

ISSUE #14: Is it possible to unify the requester-AM interaction in Section 3.5, so that you can loop on the same kind of permission-request message over and over?

When the requesting party is a natural person and the requester app is a web server app, they have to go through browser redirects, and crossing SSL-protected zones with a browser can be an ugly experience at best and a failure of an experience at worst. Sticking to GETs as a constraint for this interaction would be ideal, but if you're asked for a lot of claims, the size of the claim response could easily put a GET out of reach.

Do we need to design different paths for each "constellation"?

  • Human requesting party / web server requester app / browser
  • Human requesting party / native requester app
  • Legal-person requesting party (organization) / requester web service

What about using an artifact pattern to pass a pointer to the claims that the AM can retrieve on the back end? But then you have to successfully tie it to the session, for security.

Is it worthwhile to solve for an excruciatingly simple constellation that involves a human using a web server requester app, conveying (at least) self-asserted claims that are JWT-friendly? We'd have to revise Claims 2.0 to be JWT-friendly, which is something we meant to do anyway. Maciej and Lukasz already have thoughts on designing the protocol in this area, so let's discuss in the near future.

ISSUE#24: Should the AM return info about how the host can redirect the user to the policy definition page (sharing setting screen) on the AM once the user says they want to share something?

The NCL team found that this was a valuable UX experience. If we think it's a good idea, should it be required or optional? Maybe we should make it a requirement and then see if feedback tells us to soften it into an optional feature of the AM. But then it puts a requirement on the AM to implement a certain kind of user behavior. So maybe this should be a best-practice kind of thing, which we help be interoperable through an optional parameter.

We convinced ourselves that it should be in the core spec but optional based on this reasoning. We need a policy redirection URI. We're not sure why the AM needs to return a resource ID to the host, since the host assigned its own resource set ID to the resource set it's registering. We need to check with Lukasz/Maciej M. on this.

(We could, if we want, contribute a rev 01 as an I-D, but we're not going to put a priority on doing this prior to IETF81.)

ISSUE#15: If the content-type (of the claims response document sent by the requester) is not recognized by the AM, what happens then?

This should be an error from the AM. We need to create an error for this. George suggests that we should trap this earlier, however. If the claims-response document is provided in a POST, couldn't the AM's request (which is an HTTP response) have a Content-Type header that identifies the claims-requested format, which we can say dictates the required claims response format (which is in a POST or whatever)? Currently we say the requester uses an Accept header, but maybe we should use Content-Type on both sides throughout.

This gets into big issues of semantic interoperability at the claims stage. There are small syntax issues, and big issues of syntax+semantics that may suggest we'll end up with "horizontal" UMA requesters that handle simple cases and "vertical" ones that handle things like health data or other specific use cases.

Maybe we can look at the SAML PAOS example for inspiration, since it similarly has a request-response application protocol flowing over an HTTP response-request messaging order.

Issue #14 is still open; we need someone to propose a simple solution for the simple problem. We'll tackle the more extensive problem as we go.

ISSUE #25: What happens when a resource (being registered) already exists (Section 2.4.4)?

Our Create and Update API calls both use PUT, and Update differs only in that it has an If-Match. Is that enough to distinguish them? Do we need an error when you're Creating a resource set with an ID that already exists, and another error when you're Updating a resource set with a If-Match mismatch? (We're probably already covered on that last one.)

ISSUE #27: Can Update Resource Set Description API mistakenly overwrite/destroy an existing resource description?

It can overwrite/destroy, but that should be the intent.

ISSUE #37: Okay to cache token status as now explained? Do we need to add examples if so?

There is an Expires header that the AM can use to indicate that the token status can be cached. It's in the form of an absolute expiration date. (A cache control header of No Cache would take precedence, we believe.)

We need more advice on current good practice around indicating cache/expiration details.

ISSUE #38: Does the returned permission ticket need an expiration field (Section 3.4)?

Should we lean on an Expires header for this, to be maximally RESTful, or put something in the JSON?

ISSUE #39: MAYs/SHOULDs:

(This is "sub-issue #39a"! We've now closed it.) In Section 3.1.3, why is the host's 401 Unauthorized response to a requester with an invalid token a SHOULD instead of a MUST? We think this should be a MUST. Let's do that for now.

(This is "sub-issue #39b"! Maybe give it a new number since we haven't closed it.) In Section 3.1.4, why are the host's actions in the case of insufficient permission a SHOULD instead of a MUST? It has two components to its actions: registering a permission and returning 403 Forbidden. For completeness, we could consider the following options:

  • Host chooses to register permission; succeeds; returns 403 Forbidden with am_uri and ticket fields.
  • Host chooses not to register permission; returns 403 Forbidden without extra fields.
  • Host chooses to register permission; fails; returns 403 Forbidden without extra fields.
  • Host chooses to register permission; succeeds; chooses to return 403 Forbidden without extra fields.

We should preclude any of the options explicitly in the spec language, but we're not sure which to cross off the list yet (though the last one listed is a good candidate).

(This is "sub-issue #39c"! Maybe give it a new number since we haven't closed it.) In Section 3.2, why do we say the requester SHOULD use the client credentials authorization grant type instead of MUST?

This makes clear that the requester is not going to share tokens across its users, so it has to keep getting new ones for new users. The meaning and the "binding situation" could be confusing if we allow flows that aren't inherently "autonomous". The others all have at least an implicit relationship to the resource owner on the authorizing side, and we don't want to allow the use of any flow that has that. But if other flows come along that have "autonomy-nature", we could point to those.

The assertion flow will reappear in OAuth 2.0 draft 17. This flow could be autonomous in some cases, but you can't tell from the syntax of the messaging which one it is.

Let's not close this one yet.

We didn't get to the other "interesting" and "other" issues yet.

Next Meetings

  • WEBINAR dry-run on Monday, 11 Jul 2011, at 9-10am PT (time chart) – stay tuned for access info
  • WEBINAR on Wednesday, 13 Jul 2011, at 9-10am PT (time chart) – register here
  • No WG telecon on Thursday, 14 Jul 2011 (canceled)
  • WG telecon on Thursday, 21 Jul 2011, at 9-10:30am PT (time chart) – overlaps Cloud Identity Summit; Eve regrets?
  • WG telecon on Thursday, 28 Jul 2011, at 9-10:30am PT (time chart)
    • Skype line "C": +9900827042954214
    • US: +1-201-793-9022 (other int'l numbers) | Room Code: 295-4214