On 20 Aug 2015, at 7:16 PM, Justin Richer <jricher@mit.edu> wrote:

I think the best logic is "If ... MUST" here. Basically, tell the RS the conditions under which it needs to respond this way, then tell it exactly how to do it. Right now it's kinda "If ... SHOULD" which doesn't give client developers much that they can count on.

My personal read is that it's a minor-level revision for the reasons I said earlier in the thread (add new stuff that doesn't invalidate stuff that was specified before but might break things that weren't specified), but since it's so under-specified in 1.0.0 I can see the argument for it being a patch.

 -- Justin

On 8/20/2015 10:12 PM, Eve Maler wrote:

It says SHOULD now because, as noted below, a) 403 isn’t the only option (other responses aren’t precluded even if they’re not preferred) and b) a response isn’t strictly required at all. However, we could theoretically say that, if the RS responds at all, it MUST use the header. I don’t think anyone’s saying it’s a bad idea.

Then the only question is whether that’s a breaking change. I think it technically is, only because we didn’t require it with non-403 responses previously.

But I’m wondering if this counts as splitting hairs at this point (ymmv).

Eve

On 20 Aug 2015, at 7:05 PM, Justin Richer <jricher@mit.edu> wrote:

Is there a good reason for not making the response header a MUST in this case? "If the resource server knows where to send you (which is assumed from the text that we just added so go read that first), then it MUST tell the client where to go."

I don't see a good reason for making it be a SHOULD. If it doesn't respond with the header, then the RS isn't doing UMA. If it is doing UMA, and it doesn't respond with the header, what does that even mean?

 -- Justin

On 8/20/2015 7:09 PM, Eve Maler wrote:

Yes, that’s the kind of “parallel” optionality I was thinking of.

James mentioned an interesting observation on the call. Note that the spec says “It SHOULD respond with the HTTP 403 (Forbidden) status code, providing…” It doesn’t actually say MUST. Our intent with the SHOULD was to reinforce that 403 was preferred, but not to mandate it because all server responses are actually optional per the Sec 3 intro.

If it would thus not technically be stretching, we could perhaps craft something closer to our eventual intention, like this:

“In its response, the resource server SHOULD provide the authorization server's URI in an "as_uri" property in a WWW-Authenticate header with the authentication scheme “UMA", and the just-received permission ticket in a “ticket" property. If the resource server does not provide this header, the client has no way to know how to continue seeking access to the protected resource to which it just attempted access. For an HTTP 403 response, the RS MAY also respond with the ticket in the body in a JSON-encoded "ticket" property."

A ticket property wasn’t mandated before (didn’t exist) and it’s not strictly mandated now (SHOULD), but it’s recommended, and we expect everybody to do it routinely if they’re responding at all. A ticket body wasn’t mandated before (SHOULD) and it’s not now (MAY), but its use will fall away because it’s redundant and inconvenient for non-JSON APIs. If it’s awkward to mention the body part at all, could we even drop it, since it was never strictly required? If we went this route, should we explain what the heck is up — in the spec and/or in the UIG?

If it would be too ethically close to a breaking change, but we’re certain of our eventual intention, we could signal our later intent with a MAY phrase like yours instead of the “undefined but go look at the UIG” phrase that’s in there now.

Yours in pretzel logic,

Eve