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

[Stephen Farrell <[e-mail]>]

Hiya,

On 04/12/2013 10:03 PM, Justin Richer wrote:
> 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.

Thanks:-)

> 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? 

Seems like it needs some fix anyway. I'll mark the draft as
revised I-D needed.

> 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.

So what is a client supposed to do if it gets a 503?

>>> (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.

That'd be fine. But doesn't it need saying?

Like I said the rest are nits. But to be clear: I think we (me
and the WG) need to figure out the above before IETF LC starts.

Cheers,
S.

> 
>>>
>>> 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
> 
> 
>