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

From: Stephen Farrell <[email-masked]>
Date: Tue, 09 Apr 2013 18:27:54 +0100

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?

(2) 2.2: what's in the response body with a 200 response?  If it
doesn't matter please say so.

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.

- section 2: the "MAY include a query component" is sort of
dangling there, maybe it'd be better moved elsewhere?

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

- 2.1: ought there be a registry for token_type_hint values? It
looks like maybe there ought be.

- 2.1: "A client compliant with [RFC6749] must be prepared" was
that meant to be a 2119 MUST?

- section 6: maybe s/shall/need to/ in the last para

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 12 Apr 2013 21:53:37 +0100

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

---

From: Justin Richer <[email-masked]>
Date: Fri, 12 Apr 2013 17:03:19 -0400

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.

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

>> doesn't matter please say so.
Doesn't matter. All information is conveyed in the response code.

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

>> 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".
>> it fwiw, and have nearly cured 'em of that craze;-) Consider
WFM.
>> 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).

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 12 Apr 2013 23:39:40 +0100

Hiya,

> what little details I have are inline.

Thanks:-)

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

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

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 13 Apr 2013 11:01:47 +0200

Hi all,

what do others think regarding a registry for token_type_hint values?

regards,
Torsten.

Am 12.04.2013 um 23:03 schrieb Justin Richer <[email-masked]>:

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 15 Apr 2013 22:09:51 +0200

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

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.

> 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.
> with something from 6479.

Assuming you meant 6749 I changed it to "application"
> 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."
> it fwiw, and have nearly cured 'em of that craze;-) Consider
done
> looks like maybe there ought be.

Added registry in Section 5.1.2
> that meant to be a 2119 MUST?
yep, changed it.
> - section 6: maybe s/shall/need to/ in the last para
done

regards,
Torsten.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 Apr 2013 22:13:33 +0100

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.

> how long the service is expected to be unavailable to the requesting

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.

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