One option is something like:



The RS MUST respond with a WWW-Authenticate header in the UMA scheme, including the as_uri property. For an HTTP 403 response, the RS MUST respond with a JSON document with the ticket in the body. The RS MAY return the ticket in the header as the ticket property for a 403 response in addition to the body. For other responses, the RS MUST respond with the ticket in the header as the ticket property. The client then takes the ticket and sends it to the AS, blah blah...



This is a non-breaking change per the spec, but it specifies new behavior where before it was “undefined”. This fits a classical definition of a minor release: adding new functionality that might break some assumptions but not something specified. One could wedge it into a patch release but that seems a little bit of a stretch, to me. 

Then in 2.0, we take away the special specification around 403 and make *everything* return the ticket in the header no matter the code. This closes a bunch of stuff all at once and wouldn’t break compliant server and client implementations, which could phase out support for the JSON body and always look in the header.

 — Justin


On Aug 20, 2015, at 1:55 PM, Eve Maler <eve@xmlgrrl.com> wrote:

In discussing how to implement our decision on issue #163 last week for how to add the WWW-Authenticate header to success responses in addition to error responses when the client presents no access token, we realized that:

1. The API correctly might want to return 300-class responses in addition to 200-class responses (that is, it’s entirely up to the API what “success” means for it).

2. As long as the response contains the WWW-Authenticate: UMA header and the relevant AS location and ticket info, we don’t much care what HTTP status code is used, because this is enough to tell the client what to do next.

3. If we broaden the text to allow any status code at all instead of 403, it’s sort of non-breaking (barring the “other responses by 403 are undefined” wording that’s in there now) — noting that this also allows a 401. (Hello, issue #164. :-) This resulted in the following wording:

https://github.com/KantaraInitiative/wg-uma/commit/b784e6c33e45c02b267ad6b21ffca243063facf4

“It SHOULD respond to the client with a response that MUST include the "WWW-Authenticate" response header field with the authentication scheme "UMA", providing the authorization server's URI in an "as_uri" property in the header, along with the just-received permission ticket in the body in a JSON-encoded “ticket” property.”

- What do we think of this wording?

- If we like this wording or something similar...

4. Once we got to this point, I felt increasingly uncomfortable with leaving issue #168 to a later major version because of point no. 1. It’s crystal-clear that the API (which could just be a web app) might want to return a web page or a graphic or whatever. How do you return a JPEG along with a JSON body with a ticket in it? This issue seems not just “critical”, but “blocking”. The downside seems large, the upside seems large, and it seems like a low-impact change to the spec and implementations. The discussion in that issue seemed to be going in the direction of returning the ticket as part of the WWW-Authenticate header.

- Are we willing to choose a “breaking” solution along these lines in the patch release?

- If we’re not, would we be interested in a “non-breaking” solution along the following lines? “SHOULD provide the ticket in ticket=“ticket-value” in the header, or in the body in a JSON-encoded "ticket” property but the latter is deprecated”.

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma