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

[Stephen Farrell <[e-mail]>]

Hi Torsten,

That's great thanks.

We're still after a mail from Marius ack'ing no IPR. Be nice
to get that.

I'll ask for IETF LC in a day or so in case the WG have
anything to say, but a couple of follow-ups below that
you can take as LC comments from me.

On 04/15/2013 09:09 PM, Torsten Lodderstedt wrote:
> 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.

I think it'd be worth looking at other HTTP consuming specs and
maybe asking some folks about that. I suspect you might need to
say 5xx rather than just 503 and "reasonable" is gonna set off
transport area alarms bells probably.

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

I'd encourage WG participants to check that and see what they think.
We can fix it (if needed) after IETF LC.

Cheers,
S.

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