Hi Stephen,
I just posted a new revision of the draft
(http://tools.ietf.org/html/draft-ietf-oauth-revocation-07). I tried to
address all the issues you raised (see below).
Am 09.04.2013 19:27, schrieb Stephen Farrell:
Hi,
I've done my AD review of this draft. I have two quick questions
I'd like to get answered before I start IETF LC. Depending on the
answers maybe we should re-spin or just fire ahead, let's see...
(1) 2.1: "upon the return of the request" isn't right is it? I
think you mean the response at least.
adjusted wording to "upon receipt of an HTTP 200 response from the server"
And what about HTTP error
handling? What if I get a 503 error? Is the client supposed
to re-send ever? Don't you need to say?
Added:
If the server responds with HTTP status code 503, the client must assume
the token still exists and may retry after a reasonable delay. The
server may include a "Retry-After" header in the response to indicate
how long the service is expected to be unavailable to the requesting client.
(2) 2.2: what's in the response body with a 200 response? If it
doesn't matter please say so.
Added:
The content of the response body does not matter as all information is
conveyed in the response code.
I see from the write-up one author hasn't confirmed there are
no IPR issues. I've sent a Marius a mail so hopefully we
can sort that as we go.
I also have the following nits that can be fixed (if need
be) whenever the draft is next changed:
- intro: "app" isn't really a great term to use, can you replace
with something from 6479.
Assuming you meant 6749 I changed it to "application"
- section 2: the "MAY include a query component" is sort of
dangling there, maybe it'd be better moved elsewhere?
As Justin pointed out, the place is ok. I tried to improve wording a bit.
"The client requests the revocation of a particular token by making an
HTTP POST request to the token revocation endpoint URL. This URL MAY
include a query component."
- section 2: "MUST be obtained from a trustworthy source." might
generate comment from IESG members who don't like using 2119
terms in ways that don't affect interoperability. (I'm fine with
it fwiw, and have nearly cured 'em of that craze;-) Consider
s/MUST/need to/ here.
done
- 2.1: ought there be a registry for token_type_hint values? It
looks like maybe there ought be.
Added registry in Section 5.1.2
- 2.1: "A client compliant with [RFC6749] must be prepared" was
that meant to be a 2119 MUST?
yep, changed it.
- section 6: maybe s/shall/need to/ in the last para
done
regards,
Torsten.
Cheers,
S.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
