Hi Stephen,
I didn't respond as I didn't have anything to add to your comments, but
what little details I have are inline.
On 04/12/2013 04:53 PM, Stephen Farrell wrote:
Hi,
I'm surprised there've been no responses. I thought
there was more interest in this one.
Ta,
S.
On 04/09/2013 06:27 PM, Stephen Farrell wrote:
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. 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?
Should this read "upon receipt of an HTTP 200 response from the server"
instead? If there's a 503, the client can't assume the token is gone,
but it also probably shouldn't try spamming the endpoint, either.
(2) 2.2: what's in the response body with a 200 response? If it
doesn't matter please say so.
Doesn't matter. 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.
"app" was chosen because the application to use here could be either the
Client or the Resource Server in RFC6749, so neither is really the right
fit. It's whoever's revoking the token.
- section 2: the "MAY include a query component" is sort of
dangling there, maybe it'd be better moved elsewhere?
Don't see where else this could fit. Basically we're saying the endpoint
URL can be defined as "/endpoint?type=revoke" just as easily as "/revoke".
- 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.
WFM.
- 2.1: ought there be a registry for token_type_hint values? It
looks like maybe there ought be.
I think a registry is overkill for this kind of thing, but I suppose it
could be set up. It's meant to be a *hint* to the server as to what kind
of token it is. If it does get set up, the Introspection draft will use
it (if that ever can get either pulled into the WG or moved through as
an individual submission).
- 2.1: "A client compliant with [RFC6749] must be prepared" was
that meant to be a 2119 MUST?
This is informative, not normative. You could easily replace "must" with
"needs to" here and get the same intended meaning, which is that tokens
can disappear when you're not looking.
- section 6: maybe s/shall/need to/ in the last para
Same as above.
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
