UMA telecon 2011-05-26

Date and Time

WG telecon on Thursday, 26 May 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-05-19 meeting
Action item review
UMA Core Protocol: core spec review
AOB

Attendees

As of 19 May 2011 (pre-mtg), quorum is 7 of 12.

Catalano, Domenico
Fletcher, George
Machulak, Maciej
Moren, Lukasz
Wolniak, Maciej
Wray, Frank

Non-voting:

Cordny Nederkoorn

Regrets:

Eve Maler
Thomas Hardjono
Peter Davis
Susan Morrow

Minutes

Roll call

Quorum was NOT reached.

Action item review

2011-04-07-2 Frank, Kirk Open Match constellations to scoped access diagrams to see what happens. We'll keep tabs on this weekly and keep the item open.
2011-04-14-1 Maciej, Alam Open Build list of FAQs (both questions and candidate answers) on the wiki._Eve has created a FAQ shell; Maciej will try and add some answers.
2011-05-12-1 Eve Open Check out the possibility of running a new UMA webinar. _Pending the end of the Berlin meeting.
2011-05-12-2 Domenico Open Look into how to contribute Claims 2.0 to the OpenID ABC work. _Domenico took this over from Eve.

Frank Wray is working on the hData use case for UMA and should send more information to the list shortly. In particular, he is solving the problem of secure discovery. Maciej will try to collaborate with regards to this issue of secure discovery as this is one of the similar issues to what the SMART project has been looking into.

Review of the UMA Core Protocol Specification - issues

We discuss issues mentioned in the specification in point 11.

Issue 1 (Need to specify options for claim formats in the XRD.)
Maciej suggests that we need to provide the name of the supported claim format - i.e. claims2 or something else but not json. JSON would be used just to structure information but tells nothing about the semantics.

Issue 2 (Need to clarify how the requester's user authorization endpoint would be used in an UMA (vs. an OAuth) fashion for collecting synchronous authorizing user consent in Phase 2, based on a privileged type of claim request.)
We're not sure about the specifics of the issue - i.e. "synchronous authorizing user consent". Maciej suggests it resembles the current flow used in the SMART implementation. George has a different view on this vocabulary. We decide to move forward and leave this issue for the time being.

Issue 3 (Do we need to specify explicitly a means for the requester to get a new or refreshed access token from the AM, or can we mostly just refer to OAuth for this? Right now this interaction type doesn't have its own section.)
For refresh token we can refer to OAuth. Frank and George think this would be the best option. If refresh token is invalid and there's a need to go through the entire flow then we need to come up with new means.

Issue 4 (Need to specify the format of the token validation request message. Can Maciej supply what they're using?)
Maciej and George discuss the format of the validation request. Maciej suggests that we should use JSON in all our requests if we already started doing so. There is no benefit in URL-Encoded.

Issue 5 (When the token is invalid, what's the current OAuth thinking on what we should return? Is there any reason not to copy OAuth as closely as possible in this case? Or should a token status of "invalid" be used, and returned as success (unifying the different kinds of responses to the validation request)?)
There is a need to differentiate invalid token of the host and invalid token of the requester. These are two separate things and must be communicated differently to the host during validation.

Issue 6 & 7 (6: Need to complete the design of the requested-scope registration interaction and its associated error messages., 7: Need to complete the design of the authorization request interaction and its associated error messages.)
We have to agree on error messages in particular. We decide to leave this for the moment.

Issue 8 (Sort out whether resource set descriptions are supposed to use scope URIs or scope identifiers! It's inconsistent now.)
This has to be discussed further - no consensus.

Issue 9 (Move the resource registration API section to be a subsection under the previous big section.)
Folks at Newcastle University are concerned whether we should have the resource registration specification within the core document. George thinks its fine - this would increase interoperability. Maciej understands this - does not have a strong agreement that RR spec should be separate but thinks the core documents becomes hard to read and loses flexibility (e.g. if the spec has to be changed just in this section).

Issue 10 (Copy over the resource set description and scope description content.)
SMART team will provide examples for the specification.

Cordny then discusses the issues he mentioned in his email:

Regarding 2.2.1 - The UMA error message returning from the AM in case of a token invalid response: UMA or HTTP? Maciej also finds HTTP Success confusing. Also in 2.2.2 we should clarify what an UMA success message is.

2.3 - Is the error message indicating a malformed scope reg. request a UMA-error-message or HTTP-error-message? This has to be clarified.

4.3 Update Resource Set Description - In case of a HTTP 204 response message success), The 204 response MUST NOT include a message-body??

Why also not a HTTP error message when a previously registered resource meant to be updated was NOT found?? Cordny suggests this should be a 404 - Maciej says this is an option but also 412 (Precondition Failed) might be OK - you try to update a resource only if the ETag matches - since the resource is not there then the ETag does not match.

4.5 List Resource Set Descriptions
What if NO identifiers are found for this user, I would expect a HTTP 404 Not Found?? There might be an empty JSON - i.e. an empty list.