Re: [OAUTH-WG] AD review of draft-ietf-oauth-revocation-06

[Justin Richer <[e-mail]>]

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth