[OAUTH-WG] AD review of -22
Hi all, Sorry for having been quite slow with this, but I had a bunch of travel recently. Anyway, my AD comments on -22 are attached. I think that the first list has the ones that need some change before we push this out for IETF LC, there might or might not be something to change as a result of the 2nd list of questions and the rest are really nits can be handled either now or later. Thanks for all your work on this so far - its nearly there IMO and we should be able to get the IETF LC started once these few things are dealt with. Cheers, S. List 1 - Fairly sure these need changes: (1) In 2.3.1 MUST the AS support both HTTP basic and the client_id and client_secret in the request schemes? You say it MAY "allow" credentials in the request body, but that's different from what the AS coder has to implement. Saying an AS that issues passwords MUST support "basic over TLS" and MAY support including credentials in the body would seem right here. (2) In 2.3.1 (and more generally) what does "MUST require the use of a transport-layer security mechanism" really mean? I think you need to say explicitly what this means in terms of TLS and which version of TLS and which ciphersuites etc. Doing that once is fine and you could then have a defined phrase for it, but it needs to be specified for each place where TLS is used. The text at the end of p15 is almost exactly what's needed, and would be if you said which ciphersuites are MUSTs. I think you might need to pick ciphersuites for each version if you want some combination of tls1.0 and tls1.2 and need server auth at least. (3) Having a MUST for TLS1.0 and a SHOULD for TLS1.2 is going to generate a DISCUSS or two. I think you really need to justify that in the Document and PROTO write up if you want to stick with the current choices. I personally would prefer if those were swapped myself, that is have a MUST for the latest version of TLS (TLS1.2) and a MAY/SHOULD for TLS 1.0. In addition to taking care of process concerns, there is also the recent TLS chosen plaintext attack where TLS1.2 has no problem but TLS1.0 does. (This differs from (2) above, since the former is almost editorial, but I guess this one needs to go to the WG.) (4) The response_type description in 3.1.1 is unclear. You say it MUST be "one of" various values, but then that it can be a space separated list of values. When >1 value is provided, it doesn't say what that means, it only says that the order is irrelevant. (It could mean "any of these" or "all of these" for example, both are order independent, but are not the same.) I suggest adding a sentence to say that "code token" means "please send both" if that's what it means. (5) How does a client implement the MUST in the last sentence of 3.1.2.3? I don't see anything here or in 10.15 that says how to do this. I guess ideally, you'd just need a reference to somewhere else in the doc or to something else, but I do think you need something since you've made this a "MUST ensure" rule for clients. Adding a sentence/short paragraph here or in 10.15 with some typical/good ways to ensure this would be fine. (6) In 7.1 what does it mean to say that the client MUST NOT use the access token if it doesn't trust the token type? I don't know what code I'd write there in a client. Maybe s/trust/support/ or s/trust/understand/ would fix this. (7) Doesn't 7.1 need to say which token types are MTI so that we get interop? I think I'd like to see mac being a MUST and bearer being a MAY but regardless of my preference, I don't think you can be silent on this. One way to do this would be to mandate that the client MUST support mac and MAY support bearer but to allow the server to choose which token types they support. And as a consequence one or both of the mac/bearer drafts need to end up as normative I think. (8) 10.3 says access tokens MUST be kept confidential in transit. Does that not mean that non-anonymous TLS is a MUST? If so, then saying that clearly here would be good. If not, then saying what's really meant clearly is needed. (Same point for refresh tokens in 10.4.) (9) 10.5 says "effort should be made" to keep codes confidential, but I expect that'll generate AD comments - that's just a bit too vague - what do you really mean there? (10) 10.10 has an impossible requirement - you cannot stop/prevent attackers guessing, but you can ensure that such guessing is futile. Can you not be a bit more specific about a "reasonable" level of entropy here? I'd say 10 bits is not enough, 128 is, and there may be a good level to at least RECOMMEND (e.g. maybe >N bits if rate limiting can effectively prevent 2^(N/2) guesses going undetected? I'm not recommending an "N" myself here, but rather that the WG consider picking one or else justify not picking one. (The same comment applies to the term "non-guessable" as used in 10.12 and maybe elsewhere as well.) (11) Section 11 says a couple of times that the apps
Re: [OAUTH-WG] AD review of -22
I have not seen any responses to these items so I assume the group is in agreement with the comments made. I will push out a revised ID addressing these items in a few days. EHL From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Stephen Farrell [stephen.farr...@cs.tcd.ie] Sent: Thursday, October 13, 2011 10:13 AM To: oauth@ietf.org Subject: [OAUTH-WG] AD review of -22 Hi all, Sorry for having been quite slow with this, but I had a bunch of travel recently. Anyway, my AD comments on -22 are attached. I think that the first list has the ones that need some change before we push this out for IETF LC, there might or might not be something to change as a result of the 2nd list of questions and the rest are really nits can be handled either now or later. Thanks for all your work on this so far - its nearly there IMO and we should be able to get the IETF LC started once these few things are dealt with. Cheers, S. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD review of -22
Hi Stephen, I'm concerned about your proposal (7) to make support for MAC a MUST for clients and BEARER a MAY only. In my opinion, this does not reflect the group's consensus. Beside this, the security threat analysis justifies usage of BEARER for nearly all use cases as long as HTTPS (incl. server authentication) can be utilized. regards, Torsten. Am 13.10.2011 19:13, schrieb Stephen Farrell: Hi all, Sorry for having been quite slow with this, but I had a bunch of travel recently. Anyway, my AD comments on -22 are attached. I think that the first list has the ones that need some change before we push this out for IETF LC, there might or might not be something to change as a result of the 2nd list of questions and the rest are really nits can be handled either now or later. Thanks for all your work on this so far - its nearly there IMO and we should be able to get the IETF LC started once these few things are dealt with. 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
Re: [OAUTH-WG] AD review of -22
+1 On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote: > Hi Stephen, > > I'm concerned about your proposal (7) to make support for MAC a MUST for > clients and BEARER a MAY only. In my opinion, this does not reflect the > group's consensus. Beside this, the security threat analysis justifies usage > of BEARER for nearly all use cases as long as HTTPS (incl. server > authentication) can be utilized. > regards, > Torsten. > > Am 13.10.2011 19:13, schrieb Stephen Farrell: >> >> >> Hi all, >> >> Sorry for having been quite slow with this, but I had a bunch >> of travel recently. >> >> Anyway, my AD comments on -22 are attached. I think that the >> first list has the ones that need some change before we push >> this out for IETF LC, there might or might not be something >> to change as a result of the 2nd list of questions and the >> rest are really nits can be handled either now or later. >> >> Thanks for all your work on this so far - its nearly there >> IMO and we should be able to get the IETF LC started once >> these few things are dealt with. >> >> 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 smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD review of -22
Do you want to see no change or adjust it to client must implement both, server decides which to use. EHL From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of John Bradley [ve7...@ve7jtb.com] Sent: Wednesday, November 02, 2011 1:06 PM To: Torsten Lodderstedt Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] AD review of -22 +1 On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote: Hi Stephen, I'm concerned about your proposal (7) to make support for MAC a MUST for clients and BEARER a MAY only. In my opinion, this does not reflect the group's consensus. Beside this, the security threat analysis justifies usage of BEARER for nearly all use cases as long as HTTPS (incl. server authentication) can be utilized. regards, Torsten. Am 13.10.2011 19:13, schrieb Stephen Farrell: Hi all, Sorry for having been quite slow with this, but I had a bunch of travel recently. Anyway, my AD comments on -22 are attached. I think that the first list has the ones that need some change before we push this out for IETF LC, there might or might not be something to change as a result of the 2nd list of questions and the rest are really nits can be handled either now or later. Thanks for all your work on this so far - its nearly there IMO and we should be able to get the IETF LC started once these few things are dealt with. Cheers, S. ___ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD review of -22
+1 Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-11-02, at 1:06 PM, John Bradley wrote: > +1 > On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote: > >> Hi Stephen, >> >> I'm concerned about your proposal (7) to make support for MAC a MUST for >> clients and BEARER a MAY only. In my opinion, this does not reflect the >> group's consensus. Beside this, the security threat analysis justifies usage >> of BEARER for nearly all use cases as long as HTTPS (incl. server >> authentication) can be utilized. >> regards, >> Torsten. >> >> Am 13.10.2011 19:13, schrieb Stephen Farrell: >>> >>> >>> Hi all, >>> >>> Sorry for having been quite slow with this, but I had a bunch >>> of travel recently. >>> >>> Anyway, my AD comments on -22 are attached. I think that the >>> first list has the ones that need some change before we push >>> this out for IETF LC, there might or might not be something >>> to change as a result of the 2nd list of questions and the >>> rest are really nits can be handled either now or later. >>> >>> Thanks for all your work on this so far - its nearly there >>> IMO and we should be able to get the IETF LC started once >>> these few things are dealt with. >>> >>> 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD review of -22
+1 Leave the current text as is, keep this part of OAuth token-type agnostic. -- Justin On Wed, 2011-11-02 at 13:18 -0700, Phil Hunt wrote: > +1 > > > Phil > > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > > > > > > On 2011-11-02, at 1:06 PM, John Bradley wrote: > > > +1 > > On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote: > > > > > Hi Stephen, > > > > > > I'm concerned about your proposal (7) to make support for MAC a > > > MUST for clients and BEARER a MAY only. In my opinion, this does > > > not reflect the group's consensus. Beside this, the security > > > threat analysis justifies usage of BEARER for nearly all use cases > > > as long as HTTPS (incl. server authentication) can be utilized. > > > regards, > > > Torsten. > > > > > > Am 13.10.2011 19:13, schrieb Stephen Farrell: > > > > > > > > Hi all, > > > > > > > > Sorry for having been quite slow with this, but I had a bunch > > > > of travel recently. > > > > > > > > Anyway, my AD comments on -22 are attached. I think that the > > > > first list has the ones that need some change before we push > > > > this out for IETF LC, there might or might not be something > > > > to change as a result of the 2nd list of questions and the > > > > rest are really nits can be handled either now or later. > > > > > > > > Thanks for all your work on this so far - its nearly there > > > > IMO and we should be able to get the IETF LC started once > > > > these few things are dealt with. > > > > > > > > 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 > > > ___ > 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
Re: [OAUTH-WG] AD review of -22
Hi Torsten, On 11/02/2011 07:45 PM, Torsten Lodderstedt wrote: Hi Stephen, I'm concerned about your proposal (7) to make support for MAC a MUST for clients and BEARER a MAY only. In my opinion, this does not reflect the group's consensus. That wasn't quite my comment, which is below: (7) Doesn't 7.1 need to say which token types are MTI so that we get interop? I think I'd like to see mac being a MUST and bearer being a MAY but regardless of my preference, I don't think you can be silent on this. And as a consequence one or both of the mac/bearer drafts need to end up as normative. > Beside this, the security threat analysis justifies usage of BEARER for nearly all use cases as long as HTTPS (incl. server authentication) can be utilized. As I said, I personally prefer the mac scheme since it demonstrates use of a key. However, as I also said, the main concern with this point is interop. (I do note though that bearer has server-auth TLS as a MUST USE, so the implication of making bearer a MUST is that TLS is MTI for the base spec too and a MUST USE for anything involving the MTI token type.) In any case I can live with it so long as the set of things that are MTI is clear. Incidentally, I don't believe any amount of +1 messages to your mail answer my point above. As Eran's mail asks: what is it that you're suggesting be MTI for whom? S. regards, Torsten. Am 13.10.2011 19:13, schrieb Stephen Farrell: Hi all, Sorry for having been quite slow with this, but I had a bunch of travel recently. Anyway, my AD comments on -22 are attached. I think that the first list has the ones that need some change before we push this out for IETF LC, there might or might not be something to change as a result of the 2nd list of questions and the rest are really nits can be handled either now or later. Thanks for all your work on this so far - its nearly there IMO and we should be able to get the IETF LC started once these few things are dealt with. 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
Re: [OAUTH-WG] AD review of -22
+1 The predominant industry practice is the use of Bearer tokens, so if either of Bearer or MAC becomes Mandatory to Implement, it must be the Bearer spec, with MAC being optional. I'm fine either remaining silent on this point (leaving the spec token type agnostic, as Justin suggests), or making Bearer MTI, with MAC either being optional or not mentioned at all. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Wednesday, November 02, 2011 1:28 PM To: Phil Hunt Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] AD review of -22 +1 Leave the current text as is, keep this part of OAuth token-type agnostic. -- Justin On Wed, 2011-11-02 at 13:18 -0700, Phil Hunt wrote: > +1 > > > Phil > > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > > > > > > On 2011-11-02, at 1:06 PM, John Bradley wrote: > > > +1 > > On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote: > > > > > Hi Stephen, > > > > > > I'm concerned about your proposal (7) to make support for MAC a > > > MUST for clients and BEARER a MAY only. In my opinion, this does > > > not reflect the group's consensus. Beside this, the security > > > threat analysis justifies usage of BEARER for nearly all use cases > > > as long as HTTPS (incl. server authentication) can be utilized. > > > regards, > > > Torsten. > > > > > > Am 13.10.2011 19:13, schrieb Stephen Farrell: > > > > > > > > Hi all, > > > > > > > > Sorry for having been quite slow with this, but I had a bunch of > > > > travel recently. > > > > > > > > Anyway, my AD comments on -22 are attached. I think that the > > > > first list has the ones that need some change before we push > > > > this out for IETF LC, there might or might not be something to > > > > change as a result of the 2nd list of questions and the rest are > > > > really nits can be handled either now or later. > > > > > > > > Thanks for all your work on this so far - its nearly there IMO > > > > and we should be able to get the IETF LC started once these few > > > > things are dealt with. > > > > > > > > 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 > > > ___ > 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
Re: [OAUTH-WG] AD review of -22
Agnostic sounds like a fine word. I'd need to have it demonstrated to me that it doesn't mean non-interoperable in this case. S. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD review of -22
If the spec requires clients to implement both, the reality is most clients will only impliment one and be non compliant. Given that openID Connect supports Bearer ONLY. Requiring clients to support MAC would cause clients to implement code that won't be used. It is up to the server to decide what formats it will support. If clients can't talk to the servers they need to then they will support the token format. I am opposed to making MAC MTI for Server or client. I don't want to start a token war, there are use cases for both, and perhaps others in the future. So I think that is a Canadian way of saying no change. John B. On 2011-11-02, at 5:11 PM, Eran Hammer-Lahav wrote: > Do you want to see no change or adjust it to client must implement both, > server decides which to use. > > EHL > > From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of John > Bradley [ve7...@ve7jtb.com] > Sent: Wednesday, November 02, 2011 1:06 PM > To: Torsten Lodderstedt > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] AD review of -22 > > +1 > On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote: > >> Hi Stephen, >> >> I'm concerned about your proposal (7) to make support for MAC a MUST for >> clients and BEARER a MAY only. In my opinion, this does not reflect the >> group's consensus. Beside this, the security threat analysis justifies usage >> of BEARER for nearly all use cases as long as HTTPS (incl. server >> authentication) can be utilized. >> regards, >> Torsten. >> >> Am 13.10.2011 19:13, schrieb Stephen Farrell: >>> >>> >>> Hi all, >>> >>> Sorry for having been quite slow with this, but I had a bunch >>> of travel recently. >>> >>> Anyway, my AD comments on -22 are attached. I think that the >>> first list has the ones that need some change before we push >>> this out for IETF LC, there might or might not be something >>> to change as a result of the 2nd list of questions and the >>> rest are really nits can be handled either now or later. >>> >>> Thanks for all your work on this so far - its nearly there >>> IMO and we should be able to get the IETF LC started once >>> these few things are dealt with. >>> >>> 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 smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD review of -22
The issue is that the service provider will likely only accept ONE token format in practice. The security requirements of the scenario dictate choice of Mac or bearer or for that matter any other new scheme. An MTI would complicate the spec by implying a choice of tokens by the client because of the implication that the client has the right to select the MTI token format. Phil On 2011-11-02, at 13:31, Stephen Farrell wrote: > > Agnostic sounds like a fine word. > > I'd need to have it demonstrated to me that it doesn't > mean non-interoperable in this case. > > 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
Re: [OAUTH-WG] AD review of -22
So perhaps this is the interesting point of difference. On 11/02/2011 08:37 PM, John Bradley wrote: It is up to the server to decide what formats it will support. With IETF protocols, its IETF consensus that decides this in almost all cases that affect interop and it is therefore not up to the specific server deployment admin what the server code will support. I think this case affects interop. and should be treated as for any other IETF protocol. Am I wrong? S ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD review of -22
If we must define a mandatory token type then bearer + TLS would be my suggestion. regards, Torsten. Am 02.11.2011 21:28, schrieb Stephen Farrell: Hi Torsten, On 11/02/2011 07:45 PM, Torsten Lodderstedt wrote: Hi Stephen, I'm concerned about your proposal (7) to make support for MAC a MUST for clients and BEARER a MAY only. In my opinion, this does not reflect the group's consensus. That wasn't quite my comment, which is below: (7) Doesn't 7.1 need to say which token types are MTI so that we get interop? I think I'd like to see mac being a MUST and bearer being a MAY but regardless of my preference, I don't think you can be silent on this. And as a consequence one or both of the mac/bearer drafts need to end up as normative. > Beside this, the security threat analysis justifies usage of BEARER for nearly all use cases as long as HTTPS (incl. server authentication) can be utilized. As I said, I personally prefer the mac scheme since it demonstrates use of a key. However, as I also said, the main concern with this point is interop. (I do note though that bearer has server-auth TLS as a MUST USE, so the implication of making bearer a MUST is that TLS is MTI for the base spec too and a MUST USE for anything involving the MTI token type.) In any case I can live with it so long as the set of things that are MTI is clear. Incidentally, I don't believe any amount of +1 messages to your mail answer my point above. As Eran's mail asks: what is it that you're suggesting be MTI for whom? S. regards, Torsten. Am 13.10.2011 19:13, schrieb Stephen Farrell: Hi all, Sorry for having been quite slow with this, but I had a bunch of travel recently. Anyway, my AD comments on -22 are attached. I think that the first list has the ones that need some change before we push this out for IETF LC, there might or might not be something to change as a result of the 2nd list of questions and the rest are really nits can be handled either now or later. Thanks for all your work on this so far - its nearly there IMO and we should be able to get the IETF LC started once these few things are dealt with. 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
Re: [OAUTH-WG] AD review of -22
The problem is centered on the definition of a client. If it is a service specific implementation which is merely using OAuth for access, there isn't any interop requirements other than making sure the client and server are compatible. But if the client is a general purpose OAuth library or generic client (e.g. CURL), then the MTI becomes critical for any real interop. I don't have a strong prefernece here, but we should clearly define the client characteristics in this discussion since an OAuth client isn't usually similar to an HTTP client in its interop reality. I am not sure how to craft this language into spec form, but we might want to list such a MTI requirement in terms of a 'client designed to work across multiuple providers such as a general purpose library'. EHL From: Stephen Farrell [stephen.farr...@cs.tcd.ie] Sent: Wednesday, November 02, 2011 1:45 PM To: John Bradley Cc: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] AD review of -22 So perhaps this is the interesting point of difference. On 11/02/2011 08:37 PM, John Bradley wrote: > It is up to the server to decide what formats it will support. With IETF protocols, its IETF consensus that decides this in almost all cases that affect interop and it is therefore not up to the specific server deployment admin what the server code will support. I think this case affects interop. and should be treated as for any other IETF protocol. Am I wrong? S ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD review of -22
I could probably live with the client needing to support both token types if we quite narrowly define client as a general purpose library designed to support multiple protocols using OAuth for authorization. That however is not the general use of the term in OAuth 2.0. Many clients will be optimized to work only with Bearer + TLS knowing in advance that the protocols they are used with only require Bearer. John B. On 2011-11-02, at 5:47 PM, Eran Hammer-Lahav wrote: > The problem is centered on the definition of a client. If it is a service > specific implementation which is merely using OAuth for access, there isn't > any interop requirements other than making sure the client and server are > compatible. But if the client is a general purpose OAuth library or generic > client (e.g. CURL), then the MTI becomes critical for any real interop. > > I don't have a strong prefernece here, but we should clearly define the > client characteristics in this discussion since an OAuth client isn't usually > similar to an HTTP client in its interop reality. > > I am not sure how to craft this language into spec form, but we might want to > list such a MTI requirement in terms of a 'client designed to work across > multiuple providers such as a general purpose library'. > > EHL > > > From: Stephen Farrell [stephen.farr...@cs.tcd.ie] > Sent: Wednesday, November 02, 2011 1:45 PM > To: John Bradley > Cc: Eran Hammer-Lahav; oauth@ietf.org > Subject: Re: [OAUTH-WG] AD review of -22 > > So perhaps this is the interesting point of difference. > > On 11/02/2011 08:37 PM, John Bradley wrote: >> It is up to the server to decide what formats it will support. > > With IETF protocols, its IETF consensus that decides this in > almost all cases that affect interop and it is therefore not > up to the specific server deployment admin what the server > code will support. > > I think this case affects interop. and should be treated > as for any other IETF protocol. Am I wrong? > > S smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD review of -22
Eran's point about the definition of a client is an important one. There are two breeds of OAuth clients: (1) general purpose and (2) purpose-built for a specific OAuth service. When discussing interop, something to consider about OAuth is that discovery is not part of the core spec, which IMHO leads to many special purpose clients for a particular web service. This fits well with many OAuth use cases and isn't a bad thing, simply something that distinguishes OAuth apart from protocols like OpenID, where it is a design goal for all clients to be compatable with all OpenID identity providers. With the current OAuth landscape, to me it seems reasonable to say that clients SHOULD support both mac and bearer access token types, but MAY choose to support any access token types needed to achieve compatability with the desired server(s). Regards, Andre DeMarre On Wed, Nov 2, 2011 at 2:04 PM, John Bradley wrote: > I could probably live with the client needing to support both token types if > we quite narrowly define client as a general purpose library designed to > support multiple protocols using OAuth for authorization. > > That however is not the general use of the term in OAuth 2.0. > > Many clients will be optimized to work only with Bearer + TLS knowing in > advance that the protocols they are used with only require Bearer. > > John B. > > > > On 2011-11-02, at 5:47 PM, Eran Hammer-Lahav wrote: > >> The problem is centered on the definition of a client. If it is a service >> specific implementation which is merely using OAuth for access, there isn't >> any interop requirements other than making sure the client and server are >> compatible. But if the client is a general purpose OAuth library or generic >> client (e.g. CURL), then the MTI becomes critical for any real interop. >> >> I don't have a strong prefernece here, but we should clearly define the >> client characteristics in this discussion since an OAuth client isn't >> usually similar to an HTTP client in its interop reality. >> >> I am not sure how to craft this language into spec form, but we might want >> to list such a MTI requirement in terms of a 'client designed to work across >> multiuple providers such as a general purpose library'. >> >> EHL >> >> >> From: Stephen Farrell [stephen.farr...@cs.tcd.ie] >> Sent: Wednesday, November 02, 2011 1:45 PM >> To: John Bradley >> Cc: Eran Hammer-Lahav; oauth@ietf.org >> Subject: Re: [OAUTH-WG] AD review of -22 >> >> So perhaps this is the interesting point of difference. >> >> On 11/02/2011 08:37 PM, John Bradley wrote: >>> It is up to the server to decide what formats it will support. >> >> With IETF protocols, its IETF consensus that decides this in >> almost all cases that affect interop and it is therefore not >> up to the specific server deployment admin what the server >> code will support. >> >> I think this case affects interop. and should be treated >> as for any other IETF protocol. Am I wrong? >> >> 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
Re: [OAUTH-WG] AD review of -22
I actually think the protected resource specifies the token type(s) in either it's service docs or discovery information, and it does know knowing it's authentication server will issue compatible tokens. The client may encounter endpoints requiring token types it doesn't support, and it needs to fail gracefully. The client may select any supported OAuth 2 scheme it understands which the PR supports. I am not in favor of specifying MUST for any particular flavor of token. What is the value of mandating a token type? -bill From: Eran Hammer-Lahav To: John Bradley ; Torsten Lodderstedt Cc: "oauth@ietf.org" Sent: Wednesday, November 2, 2011 1:11 PM Subject: Re: [OAUTH-WG] AD review of -22 Do you want to see no change or adjust it to client must implement both, server decides which to use. EHL From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of John Bradley [ve7...@ve7jtb.com] Sent: Wednesday, November 02, 2011 1:06 PM To: Torsten Lodderstedt Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] AD review of -22 +1 On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote: Hi Stephen, > >I'm concerned about your proposal (7) to make support for MAC a MUST for >clients and BEARER a MAY only. In my opinion, this does not reflect the >group's consensus. Beside this, the security threat analysis justifies usage >of BEARER for nearly all use cases as long as HTTPS (incl. server authentication) can be utilized. > >regards, Torsten. >Am 13.10.2011 19:13, schrieb Stephen Farrell: > >>Hi all, >> >>Sorry for having been quite slow with this, but I had a bunch >>of travel recently. >> >>Anyway, my AD comments on -22 are attached. I think that the >>first list has the ones that need some change before we push >>this out for IETF LC, there might or might not be something >>to change as a result of the 2nd list of questions and the >>rest are really nits can be handled either now or later. >> >>Thanks for all your work on this so far - its nearly there >>IMO and we should be able to get the IETF LC started once >>these few things are dealt with. >> >>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___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD review of -22
This is exactly what I was thinking of. If a given token type is MTI for clients, but servers can do whatever they want (this, as I read it, is what was suggested), how does the MTI bit help interop at all? -- Justin On Wed, 2011-11-02 at 15:48 -0700, William Mills wrote: > I actually think the protected resource specifies the token type(s) in > either it's service docs or discovery information, and it does know > knowing it's authentication server will issue compatible tokens. The > client may encounter endpoints requiring token types it doesn't > support, and it needs to fail gracefully. The client may select any > supported OAuth 2 scheme it understands which the PR supports. > > > > I am not in favor of specifying MUST for any particular flavor of > token. > > > What is the value of mandating a token type? > > > > -bill > > > > > __ > From: Eran Hammer-Lahav > To: John Bradley ; Torsten Lodderstedt > > Cc: "oauth@ietf.org" > Sent: Wednesday, November 2, 2011 1:11 PM > Subject: Re: [OAUTH-WG] AD review of -22 > > Do you want to see no change or adjust it to client must implement > both, server decides which to use. > > EHL > > > __ > From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of > John Bradley [ve7...@ve7jtb.com] > Sent: Wednesday, November 02, 2011 1:06 PM > To: Torsten Lodderstedt > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] AD review of -22 > > > > +1 > On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote: > > > Hi Stephen, > > > > I'm concerned about your proposal (7) to make support for MAC a MUST > > for clients and BEARER a MAY only. In my opinion, this does not > > reflect the group's consensus. Beside this, the security threat > > analysis justifies usage of BEARER for nearly all use cases as long > > as HTTPS (incl. server authentication) can be utilized. > > regards, > > Torsten. > > > > Am 13.10.2011 19:13, schrieb Stephen Farrell: > > > > > > Hi all, > > > > > > Sorry for having been quite slow with this, but I had a bunch > > > of travel recently. > > > > > > Anyway, my AD comments on -22 are attached. I think that the > > > first list has the ones that need some change before we push > > > this out for IETF LC, there might or might not be something > > > to change as a result of the 2nd list of questions and the > > > rest are really nits can be handled either now or later. > > > > > > Thanks for all your work on this so far - its nearly there > > > IMO and we should be able to get the IETF LC started once > > > these few things are dealt with. > > > > > > 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 > > > > ___ > 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
Re: [OAUTH-WG] AD review of -22
It can help by telling servers that as long as they support one of the MTI types, they will be able to interop. Of course, they don't have to. My feeling is that until there is an actual discovery experience out there that works, this kind of interop is not really an issue ATM. EHL > -Original Message- > From: Justin Richer [mailto:jric...@mitre.org] > Sent: Thursday, November 03, 2011 5:46 AM > To: William Mills > Cc: Eran Hammer-Lahav; John Bradley; Torsten Lodderstedt; oauth@ietf.org > Subject: Re: [OAUTH-WG] AD review of -22 > > This is exactly what I was thinking of. If a given token type is MTI for > clients, > but servers can do whatever they want (this, as I read it, is what was > suggested), how does the MTI bit help interop at all? > > -- Justin > > On Wed, 2011-11-02 at 15:48 -0700, William Mills wrote: > > I actually think the protected resource specifies the token type(s) in > > either it's service docs or discovery information, and it does know > > knowing it's authentication server will issue compatible tokens. The > > client may encounter endpoints requiring token types it doesn't > > support, and it needs to fail gracefully. The client may select any > > supported OAuth 2 scheme it understands which the PR supports. > > > > > > > > I am not in favor of specifying MUST for any particular flavor of > > token. > > > > > > What is the value of mandating a token type? > > > > > > > > -bill > > > > > > > > > > > __________________ > > > From: Eran Hammer-Lahav > > To: John Bradley ; Torsten Lodderstedt > > > > Cc: "oauth@ietf.org" > > Sent: Wednesday, November 2, 2011 1:11 PM > > Subject: Re: [OAUTH-WG] AD review of -22 > > > > Do you want to see no change or adjust it to client must implement > > both, server decides which to use. > > > > EHL > > > > > > > ______________ > > > From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of > > John Bradley [ve7...@ve7jtb.com] > > Sent: Wednesday, November 02, 2011 1:06 PM > > To: Torsten Lodderstedt > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] AD review of -22 > > > > > > > > +1 > > On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote: > > > > > Hi Stephen, > > > > > > I'm concerned about your proposal (7) to make support for MAC a MUST > > > for clients and BEARER a MAY only. In my opinion, this does not > > > reflect the group's consensus. Beside this, the security threat > > > analysis justifies usage of BEARER for nearly all use cases as long > > > as HTTPS (incl. server authentication) can be utilized. > > > regards, > > > Torsten. > > > > > > Am 13.10.2011 19:13, schrieb Stephen Farrell: > > > > > > > > Hi all, > > > > > > > > Sorry for having been quite slow with this, but I had a bunch of > > > > travel recently. > > > > > > > > Anyway, my AD comments on -22 are attached. I think that the first > > > > list has the ones that need some change before we push this out > > > > for IETF LC, there might or might not be something to change as a > > > > result of the 2nd list of questions and the rest are really nits > > > > can be handled either now or later. > > > > > > > > Thanks for all your work on this so far - its nearly there IMO and > > > > we should be able to get the IETF LC started once these few things > > > > are dealt with. > > > > > > > > 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 > > > > > > > > ___ > > 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
Re: [OAUTH-WG] AD review of -22
+1 I note that RFCs 2616 & 2617 only reference each other. There is no MTI text. It just references them. It may be reasonable to observe that there are two classes of tokens Bearer, where the client treats token as opaque to return to server at appropriate times, and client-proof tokens such as MAC where the client must do something to prove possession with the objective that an attacker sniffing a client's authentication header (due to non-ssl communication) could not become or masquerade as the client. Do we need an analogue to the bearer spec that lays foundations for the class of tokens that MAC fits into? Or should the bearer spec be modified to explain the two classes of tokens? If we had both, then we could set this up much like HTTP 1.1 does with RFC 2617. Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-11-03, at 9:25 AM, Eran Hammer-Lahav wrote: > It can help by telling servers that as long as they support one of the MTI > types, they will be able to interop. Of course, they don't have to. > > My feeling is that until there is an actual discovery experience out there > that works, this kind of interop is not really an issue ATM. > > EHL > >> -Original Message- >> From: Justin Richer [mailto:jric...@mitre.org] >> Sent: Thursday, November 03, 2011 5:46 AM >> To: William Mills >> Cc: Eran Hammer-Lahav; John Bradley; Torsten Lodderstedt; oauth@ietf.org >> Subject: Re: [OAUTH-WG] AD review of -22 >> >> This is exactly what I was thinking of. If a given token type is MTI for >> clients, >> but servers can do whatever they want (this, as I read it, is what was >> suggested), how does the MTI bit help interop at all? >> >> -- Justin >> >> On Wed, 2011-11-02 at 15:48 -0700, William Mills wrote: >>> I actually think the protected resource specifies the token type(s) in >>> either it's service docs or discovery information, and it does know >>> knowing it's authentication server will issue compatible tokens. The >>> client may encounter endpoints requiring token types it doesn't >>> support, and it needs to fail gracefully. The client may select any >>> supported OAuth 2 scheme it understands which the PR supports. >>> >>> >>> >>> I am not in favor of specifying MUST for any particular flavor of >>> token. >>> >>> >>> What is the value of mandating a token type? >>> >>> >>> >>> -bill >>> >>> >>> >>> >>> >> __ >> >>> From: Eran Hammer-Lahav >>> To: John Bradley ; Torsten Lodderstedt >>> >>> Cc: "oauth@ietf.org" >>> Sent: Wednesday, November 2, 2011 1:11 PM >>> Subject: Re: [OAUTH-WG] AD review of -22 >>> >>> Do you want to see no change or adjust it to client must implement >>> both, server decides which to use. >>> >>> EHL >>> >>> >>> >> __ >> >>> From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of >>> John Bradley [ve7...@ve7jtb.com] >>> Sent: Wednesday, November 02, 2011 1:06 PM >>> To: Torsten Lodderstedt >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] AD review of -22 >>> >>> >>> >>> +1 >>> On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote: >>> >>>> Hi Stephen, >>>> >>>> I'm concerned about your proposal (7) to make support for MAC a MUST >>>> for clients and BEARER a MAY only. In my opinion, this does not >>>> reflect the group's consensus. Beside this, the security threat >>>> analysis justifies usage of BEARER for nearly all use cases as long >>>> as HTTPS (incl. server authentication) can be utilized. >>>> regards, >>>> Torsten. >>>> >>>> Am 13.10.2011 19:13, schrieb Stephen Farrell: >>>>> >>>>> Hi all, >>>>> >>>>> Sorry for having been quite slow with this, but I had a bunch of >>>>> travel recently. >>>>> >>>>> Anyway, my AD comments on -22 are attached. I think that the first >>>>> list has the ones that need some change before we push this out >>>>> for IETF LC, there might or might not be something to change as a >>>>> result of the 2nd list of questi
Re: [OAUTH-WG] AD review of -22
On 11/03/2011 09:25 AM, Eran Hammer-Lahav wrote: It can help by telling servers that as long as they support one of the MTI types, they will be able to interop. Of course, they don't have to. My feeling is that until there is an actual discovery experience out there that works, this kind of interop is not really an issue ATM. From what I can tell as a developer, it seems that every oauth server deployment comes with their very own oauth client library/sdk. So there's a twitter one, a g+ one, a fb one, etc. Ultimately there may be an oauth equivalent to openssl, but it's not there afaik, and probably won't be for a while since the library/sdk needs to support php, perl, python, ruby, blah, blah, blah instead of just a C library with higher level language specific veneers on top of it as needed. So the reality is that any unified client is going to have to support what servers demand, not the other way around. Which means it's going to have to be a kitchen sink client library to handle the various choices that servers make. So I'd say no to any form of an sdp-like* offer/answer protocol; it's just easier to keep adding to the client kitchen sink. Mike [*] sdp offer/answer was necessary because of _hardware_ limitations... usually because of codec complexity where an endpoint physically might not be able to interoperate. that's good motivation. I doubt there's anything comparable with oauth. EHL -Original Message- From: Justin Richer [mailto:jric...@mitre.org] Sent: Thursday, November 03, 2011 5:46 AM To: William Mills Cc: Eran Hammer-Lahav; John Bradley; Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] AD review of -22 This is exactly what I was thinking of. If a given token type is MTI for clients, but servers can do whatever they want (this, as I read it, is what was suggested), how does the MTI bit help interop at all? -- Justin On Wed, 2011-11-02 at 15:48 -0700, William Mills wrote: I actually think the protected resource specifies the token type(s) in either it's service docs or discovery information, and it does know knowing it's authentication server will issue compatible tokens. The client may encounter endpoints requiring token types it doesn't support, and it needs to fail gracefully. The client may select any supported OAuth 2 scheme it understands which the PR supports. I am not in favor of specifying MUST for any particular flavor of token. What is the value of mandating a token type? -bill __ From: Eran Hammer-Lahav To: John Bradley; Torsten Lodderstedt Cc: "oauth@ietf.org" Sent: Wednesday, November 2, 2011 1:11 PM Subject: Re: [OAUTH-WG] AD review of -22 Do you want to see no change or adjust it to client must implement both, server decides which to use. EHL __ From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of John Bradley [ve7...@ve7jtb.com] Sent: Wednesday, November 02, 2011 1:06 PM To: Torsten Lodderstedt Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] AD review of -22 +1 On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote: Hi Stephen, I'm concerned about your proposal (7) to make support for MAC a MUST for clients and BEARER a MAY only. In my opinion, this does not reflect the group's consensus. Beside this, the security threat analysis justifies usage of BEARER for nearly all use cases as long as HTTPS (incl. server authentication) can be utilized. regards, Torsten. Am 13.10.2011 19:13, schrieb Stephen Farrell: Hi all, Sorry for having been quite slow with this, but I had a bunch of travel recently. Anyway, my AD comments on -22 are attached. I think that the first list has the ones that need some change before we push this out for IETF LC, there might or might not be something to change as a result of the 2nd list of questions and the rest are really nits can be handled either now or later. Thanks for all your work on this so far - its nearly there IMO and we should be able to get the IETF LC started once these few things are dealt with. 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 ___ 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/oaut
Re: [OAUTH-WG] AD review of -22
At this point in the process I think it would be better to add that to the threat model draft. It would be appropriate to add it in the core spec, but not a good idea now that it's deep into the last call? From: Phil Hunt To: Eran Hammer-Lahav Cc: Justin Richer ; William Mills ; "oauth@ietf.org" Sent: Thursday, November 3, 2011 9:47 AM Subject: Re: [OAUTH-WG] AD review of -22 +1 I note that RFCs 2616 & 2617 only reference each other. There is no MTI text. It just references them. It may be reasonable to observe that there are two classes of tokens Bearer, where the client treats token as opaque to return to server at appropriate times, and client-proof tokens such as MAC where the client must do something to prove possession with the objective that an attacker sniffing a client's authentication header (due to non-ssl communication) could not become or masquerade as the client. Do we need an analogue to the bearer spec that lays foundations for the class of tokens that MAC fits into? Or should the bearer spec be modified to explain the two classes of tokens? If we had both, then we could set this up much like HTTP 1.1 does with RFC 2617. Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-11-03, at 9:25 AM, Eran Hammer-Lahav wrote: > It can help by telling servers that as long as they support one of the MTI > types, they will be able to interop. Of course, they don't have to. > > My feeling is that until there is an actual discovery experience out there > that works, this kind of interop is not really an issue ATM. > > EHL > >> -Original Message- >> From: Justin Richer [mailto:jric...@mitre.org] >> Sent: Thursday, November 03, 2011 5:46 AM >> To: William Mills >> Cc: Eran Hammer-Lahav; John Bradley; Torsten Lodderstedt; oauth@ietf.org >> Subject: Re: [OAUTH-WG] AD review of -22 >> >> This is exactly what I was thinking of. If a given token type is MTI for >> clients, >> but servers can do whatever they want (this, as I read it, is what was >> suggested), how does the MTI bit help interop at all? >> >> -- Justin >> >> On Wed, 2011-11-02 at 15:48 -0700, William Mills wrote: >>> I actually think the protected resource specifies the token type(s) in >>> either it's service docs or discovery information, and it does know >>> knowing it's authentication server will issue compatible tokens. The >>> client may encounter endpoints requiring token types it doesn't >>> support, and it needs to fail gracefully. The client may select any >>> supported OAuth 2 scheme it understands which the PR supports. >>> >>> >>> >>> I am not in favor of specifying MUST for any particular flavor of >>> token. >>> >>> >>> What is the value of mandating a token type? >>> >>> >>> >>> -bill >>> >>> >>> >>> >>> >> __ >> >>> From: Eran Hammer-Lahav >>> To: John Bradley ; Torsten Lodderstedt >>> >>> Cc: "oauth@ietf.org" >>> Sent: Wednesday, November 2, 2011 1:11 PM >>> Subject: Re: [OAUTH-WG] AD review of -22 >>> >>> Do you want to see no change or adjust it to client must implement >>> both, server decides which to use. >>> >>> EHL >>> >>> >>> >> __ >> >>> From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of >>> John Bradley [ve7...@ve7jtb.com] >>> Sent: Wednesday, November 02, 2011 1:06 PM >>> To: Torsten Lodderstedt >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] AD review of -22 >>> >>> >>> >>> +1 >>> On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote: >>> >>>> Hi Stephen, >>>> >>>> I'm concerned about your proposal (7) to make support for MAC a MUST >>>> for clients and BEARER a MAY only. In my opinion, this does not >>>> reflect the group's consensus. Beside this, the security threat >>>> analysis justifies usage of BEARER for nearly all use cases as long >>>> as HTTPS (incl. server authentication) can be utilized. >>>> regards, >>>> Torsten. >>>> >>>> Am 13.10.2011 19:13, schrieb Stephen Farrell: >>>>> >>>>> Hi all, >&g
Re: [OAUTH-WG] AD Review of -22 (part I)
> -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Stephen Farrell > Sent: Thursday, October 13, 2011 10:13 AM > List 1 - Fairly sure these need changes: > > > (1) In 2.3.1 MUST the AS support both HTTP basic and the client_id and > client_secret in the request schemes? You say it MAY "allow" > credentials in the request body, but that's different from what the AS coder > has to implement. Saying an AS that issues passwords MUST support "basic > over TLS" and MAY support including credentials in the body would seem > right here. Changed 'MAY allow' to 'MAY support'. Clarified the TLS requirement for sending passwords. > (2) In 2.3.1 (and more generally) what does "MUST require the use of a > transport-layer security mechanism" really mean? I think you need to say > explicitly what this means in terms of TLS and which version of TLS and which > cipher suites etc. Doing that once is fine and you could then have a defined > phrase for it, but it needs to be specified for each place where TLS is used. > The text at the end of > p15 is almost exactly what's needed, and would be if you said which cipher > suites are MUSTs. I think you might need to pick cipher suites for each > version if you want some combination of tls1.0 and tls1.2 and need server > auth at least. Replaced ' transport-layer' with TLS with reference to the new section. > (3) Having a MUST for TLS1.0 and a SHOULD for TLS1.2 is going to generate a > DISCUSS or two. I think you really need to justify that in the Document and > PROTO write up if you want to stick with the current choices. I personally > would prefer if those were swapped myself, that is have a MUST for the > latest version of TLS (TLS1.2) and a MAY/SHOULD for TLS 1.0. In addition to > taking care of process concerns, there is also the recent TLS chosen plaintext > attack where TLS1.2 has no problem but TLS1.0 does. (This differs from (2) > above, since the former is almost editorial, but I guess this one needs to go > to the WG.) This has been resolved by the chair and adjusted as such. > (4) The response_type description in 3.1.1 is unclear. You say it MUST be > "one of" various values, but then that it can be a space separated list of > values. When >1 value is provided, it doesn't say what that means, it only > says that the order is irrelevant. (It could mean "any of these" or "all of > these" for example, both are order independent, but are not the same.) I > suggest adding a sentence to say that "code token" means "please send > both" if that's what it means. Removed the space-delimited text from the end of the response_type parameter definition and added the following immediate after: Extension response types MAY contain a space-delimited (%x20) list of values, where the order of values does not matter (e.g. response type"a b" is the same as "b a"). The meaning of such composite response types is defined by their respective specifications. > (5) How does a client implement the MUST in the last sentence of 3.1.2.3? I > don't see anything here or in 10.15 that says how to do this. I guess ideally, > you'd just need a reference to somewhere else in the doc or to something > else, but I do think you need something since you've made this a "MUST > ensure" rule for clients. > Adding a sentence/short paragraph here or in 10.15 with some typical/good > ways to ensure this would be fine. I took that last paragraph out. Client mitigation isn't really practical here. > (6) In 7.1 what does it mean to say that the client MUST NOT use the access > token if it doesn't trust the token type? I don't know what code I'd write > there in a client. Maybe s/trust/support/ or s/trust/understand/ would fix > this. Took 'trust' out. > (7) Doesn't 7.1 need to say which token types are MTI so that we get > interop? I think I'd like to see mac being a MUST and bearer being a MAY but > regardless of my preference, I don't think you can be silent on this. One way > to do this would be to mandate that the client MUST support mac and MAY > support bearer but to allow the server to choose which token types they > support. And as a consequence one or both of the mac/bearer drafts need > to end up as normative I think. No change as resolved by the chair. > (8) 10.3 says access tokens MUST be kept confidential in transit. > Does that not mean that non-anonymous TLS is a MUST? If so, then saying > that clearly here would be good. If not, then saying what's really meant > clearly is needed. (Same point for refresh tokens in > 10.4.) Added to each section: [Access token credentials | Refresh tokens] MUST only be transmitted using TLS as described in with server authentication as defined by . > (9) 10.5 says "effort should be made" to keep codes confidential, but I expect > that'll generate AD comments - that's just
Re: [OAUTH-WG] AD Review of -22 (part I)
FWIW, from my p-o-v everything here is either ok, me being dumb (the password one, I need to check), part of some other thread, or stuff that's ok to resolve if necessary at IETF LC or later. So - I'd say firing away with -23 and getting this out the door (once current threads resolve themselves) is the way to go. Thanks, S. On 01/20/2012 11:47 PM, Eran Hammer wrote: -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Thursday, October 13, 2011 10:13 AM List 1 - Fairly sure these need changes: (1) In 2.3.1 MUST the AS support both HTTP basic and the client_id and client_secret in the request schemes? You say it MAY "allow" credentials in the request body, but that's different from what the AS coder has to implement. Saying an AS that issues passwords MUST support "basic over TLS" and MAY support including credentials in the body would seem right here. Changed 'MAY allow' to 'MAY support'. Clarified the TLS requirement for sending passwords. (2) In 2.3.1 (and more generally) what does "MUST require the use of a transport-layer security mechanism" really mean? I think you need to say explicitly what this means in terms of TLS and which version of TLS and which cipher suites etc. Doing that once is fine and you could then have a defined phrase for it, but it needs to be specified for each place where TLS is used. The text at the end of p15 is almost exactly what's needed, and would be if you said which cipher suites are MUSTs. I think you might need to pick cipher suites for each version if you want some combination of tls1.0 and tls1.2 and need server auth at least. Replaced ' transport-layer' with TLS with reference to the new section. (3) Having a MUST for TLS1.0 and a SHOULD for TLS1.2 is going to generate a DISCUSS or two. I think you really need to justify that in the Document and PROTO write up if you want to stick with the current choices. I personally would prefer if those were swapped myself, that is have a MUST for the latest version of TLS (TLS1.2) and a MAY/SHOULD for TLS 1.0. In addition to taking care of process concerns, there is also the recent TLS chosen plaintext attack where TLS1.2 has no problem but TLS1.0 does. (This differs from (2) above, since the former is almost editorial, but I guess this one needs to go to the WG.) This has been resolved by the chair and adjusted as such. (4) The response_type description in 3.1.1 is unclear. You say it MUST be "one of" various values, but then that it can be a space separated list of values. When>1 value is provided, it doesn't say what that means, it only says that the order is irrelevant. (It could mean "any of these" or "all of these" for example, both are order independent, but are not the same.) I suggest adding a sentence to say that "code token" means "please send both" if that's what it means. Removed the space-delimited text from the end of the response_type parameter definition and added the following immediate after: Extension response types MAY contain a space-delimited (%x20) list of values, where the order of values does not matter (e.g. response type"a b" is the same as "b a"). The meaning of such composite response types is defined by their respective specifications. (5) How does a client implement the MUST in the last sentence of 3.1.2.3? I don't see anything here or in 10.15 that says how to do this. I guess ideally, you'd just need a reference to somewhere else in the doc or to something else, but I do think you need something since you've made this a "MUST ensure" rule for clients. Adding a sentence/short paragraph here or in 10.15 with some typical/good ways to ensure this would be fine. I took that last paragraph out. Client mitigation isn't really practical here. (6) In 7.1 what does it mean to say that the client MUST NOT use the access token if it doesn't trust the token type? I don't know what code I'd write there in a client. Maybe s/trust/support/ or s/trust/understand/ would fix this. Took 'trust' out. (7) Doesn't 7.1 need to say which token types are MTI so that we get interop? I think I'd like to see mac being a MUST and bearer being a MAY but regardless of my preference, I don't think you can be silent on this. One way to do this would be to mandate that the client MUST support mac and MAY support bearer but to allow the server to choose which token types they support. And as a consequence one or both of the mac/bearer drafts need to end up as normative I think. No change as resolved by the chair. (8) 10.3 says access tokens MUST be kept confidential in transit. Does that not mean that non-anonymous TLS is a MUST? If so, then saying that clearly here would be good. If not, then saying what's really meant clearly is needed. (Same point for refresh tokens in 10.4.) Added to each section: [Access t
Re: [OAUTH-WG] AD Review of -22 (part II)
> -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Stephen Farrell > Sent: Thursday, October 13, 2011 10:13 AM > Suggested non-trivial clarifications: > - > > (1) 1.3.4 - "previously arranged" might trigger discusses on the document > since it implies that this spec might not be suited for broad use. I think > that > making it clear that the normal mode for client developers is to work against > an existing service (AS and resource server) would help to clarify that such > arrangements are ok here. Added new 'Interoperability' section to the introduction: OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, this specification is likely to produce a wide range of non-interoperable implementations. In addition, this specification leaves a few required components partially or fully undefined (e.g. client registration, authorization server capabilities, endpoint discovery). This protocol was design with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability. There is no way to sugar coat reality and hopefully by being blunt about it upfront, we will avoid a prolonged debate about the protocol's failings in that regard. > (2) p11, in step (F) is there a way to distinguish between an access token > that > is invalid due to expiry vs. e.g. data corruption? Section 6 refers to 5.2 > for the > error codes but its not clear to me which one is returned for this case. I > think > clarifying that in section 6 or 5.2 is needed. That depends on the token specification. Steps C-F are outside the scope of this document. I'll note that. > (3) p13, 2.2 and 2.3 - these things happens at registration time right? I > think > making that clear is needed since we don't specify a registration protocol > here. The entire section 2 is 'Client Registration' which is described as out of scope for implementation details. > (4) 2.3.1 uses the term "token endpoint" without definition (its defined in > section 3) and in particular without making it clear if both access and > refresh > token issuance is covered (I guess it is). Changed to 'when sending requests using password authentication'. > (5) The same text about x-www-form-urlencoded is repeated various times, > it'd be better to do that once and refer to it where necessary. Not enough to be worth the change. > (6) 3.1.2.2 states the rules for when AS'es are to require registration of > redirection URIs. I think you need to clarify that some. First, you use the > term > "redirection_uri" for both a "complete" URI and for a scheme/authority/path > triple that can be added to via a query component which is confusing. > Second, its overall a very complex rule with a MUST, two MAYs and 3 > SHOULDs. I do think it could be made clearer by putting the MUST up front > and separating issues related to complete URI and triples separately from the > when something MUST be registered. New text: The authorization server MUST require the following clients to register their redirection endpoint: o Public clients. o Confidential clients utilizing the implicit grant type. The authorization server SHOULD require all clients to register their redirection endpoint prior to utilizing the authorization endpoint The authorization server SHOULD require the client to provide the complete redirection URI (the client MAY use the "state" request parameter to achieve per-request customization). If requiring the registration of the complete redirection URI is not possible, the authorization server SHOULD require the registration of the URI scheme, authority, and path (allowing the client to dynamically vary only the query component of the redirection URI when requesting authorization). The authorization server MAY allow the client to register multiple redirection endpoints. Lack of a redirection URI registration requirement can enable an attacker to use the authorization endpoint as open redirector as described in Section 10.15. > (7) 4.2.1 and elsewhere - refers back to 3.1.2 for the way in which the > redirection-uri is OPTIONAL - I'm not sure that's sufficiently clear, 3.1.2 is > quite long and discusses a bunch of things - couldn't it be made clearer when > the messages are defined? The reference is not for the OPTIONAL definition. I changed the coma to a period. > More generally, is there no way to avoid the > extensive cross-referencing in the message field definitions? E.g. 4.2.2 has > references to 7.1 and 3.3, and others are similar. Organizing the text for the > benefit of the reader is a good thing so would
Re: [OAUTH-WG] AD Review of -22 (part II)
Same response as for part I from me, S On 01/21/2012 01:04 AM, Eran Hammer wrote: -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Thursday, October 13, 2011 10:13 AM Suggested non-trivial clarifications: - (1) 1.3.4 - "previously arranged" might trigger discusses on the document since it implies that this spec might not be suited for broad use. I think that making it clear that the normal mode for client developers is to work against an existing service (AS and resource server) would help to clarify that such arrangements are ok here. Added new 'Interoperability' section to the introduction: OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, this specification is likely to produce a wide range of non-interoperable implementations. In addition, this specification leaves a few required components partially or fully undefined (e.g. client registration, authorization server capabilities, endpoint discovery). This protocol was design with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability. There is no way to sugar coat reality and hopefully by being blunt about it upfront, we will avoid a prolonged debate about the protocol's failings in that regard. (2) p11, in step (F) is there a way to distinguish between an access token that is invalid due to expiry vs. e.g. data corruption? Section 6 refers to 5.2 for the error codes but its not clear to me which one is returned for this case. I think clarifying that in section 6 or 5.2 is needed. That depends on the token specification. Steps C-F are outside the scope of this document. I'll note that. (3) p13, 2.2 and 2.3 - these things happens at registration time right? I think making that clear is needed since we don't specify a registration protocol here. The entire section 2 is 'Client Registration' which is described as out of scope for implementation details. (4) 2.3.1 uses the term "token endpoint" without definition (its defined in section 3) and in particular without making it clear if both access and refresh token issuance is covered (I guess it is). Changed to 'when sending requests using password authentication'. (5) The same text about x-www-form-urlencoded is repeated various times, it'd be better to do that once and refer to it where necessary. Not enough to be worth the change. (6) 3.1.2.2 states the rules for when AS'es are to require registration of redirection URIs. I think you need to clarify that some. First, you use the term "redirection_uri" for both a "complete" URI and for a scheme/authority/path triple that can be added to via a query component which is confusing. Second, its overall a very complex rule with a MUST, two MAYs and 3 SHOULDs. I do think it could be made clearer by putting the MUST up front and separating issues related to complete URI and triples separately from the when something MUST be registered. New text: The authorization server MUST require the following clients to register their redirection endpoint: o Public clients. o Confidential clients utilizing the implicit grant type. The authorization server SHOULD require all clients to register their redirection endpoint prior to utilizing the authorization endpoint The authorization server SHOULD require the client to provide the complete redirection URI (the client MAY use the "state" request parameter to achieve per-request customization). If requiring the registration of the complete redirection URI is not possible, the authorization server SHOULD require the registration of the URI scheme, authority, and path (allowing the client to dynamically vary only the query component of the redirection URI when requesting authorization). The authorization server MAY allow the client to register multiple redirection endpoints. Lack of a redirection URI registration requirement can enable an attacker to use the authorization endpoint as open redirector as described in Section 10.15. (7) 4.2.1 and elsewhere - refers back to 3.1.2 for the way in which the redirection-uri is OPTIONAL - I'm not sure that's sufficiently clear, 3.1.2 is quite long and discusses a bunch of things - couldn't it be made clearer when the messages are defined? The reference is not for the OPTIONAL definition. I changed the coma to a period. More generally, is there no way to avoid the extensive cross-referencing in the message field definitions? E.g. 4.2.2 has references to 7.1 and 3.3, and others are similar. Organizing the text for the benefit of the reader is a
Re: [OAUTH-WG] AD Review of -22 (part III)
> -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Stephen Farrell > Sent: Thursday, October 13, 2011 10:13 AM > Original list of nits: > -- > > - Intro: Maybe add some ascii-art showing the roles of the user, browser, > client etc. The term client as used here is still commonly confusing and > especially worth going the extra mile to clarify, before it is first used. > What I > think needs to be said early is that what is here called a client is normally > (running on) a web server. Happy to take suggestions, but can't come up with a useful diagram myself. Added to the client definition: The term client does not imply any particular implementation characteristics (e.g. whether the application executes on a server, a desktop, or other devices). > - p4: Maybe s/a string/an octet string/ in the token descriptions, unless the > access token encoding is constrained to what'd be understood as a string. Just a string. > - p8: Seems odd to speak of "issuing" an implicit grant - wouldn't that make > something explicit? Maybe say "With an implicit grant..." > instead in the 2nd para of 1.3.2? Changed to 'When issuing an access token during the implicit grant flow'. > - p8: I don't get what "its device operating system" means. Do you mean the > client is an already-trusted part of the resource owner's device OS? Changed to 'the client is part of the device operating system'. > - p9 - "Issuing a refresh token is optional" - might be better to say that > it's the > authorization server's choice and there's no way for the client to signal a > request for one. Changed to 'Issuing a refresh token is optional at the discretion of the authorization server.' > - p10 - In figure 2, why is the Refresh token shown as optional in step (H) > but > not in step (B)? I think it'd be clearer for the figure to reflect the > protocol > options and say that the refresh token is optional in (B) as well. Because this is the refresh token flow. If it is optional, there is no flow... > - p12 - the confidential/public terminology isn't great, did the WG consider > "authenticating" vs. "non-authenticating"? Trying again to find better terms > would maybe be worthwhile. Didn't try this particular alternative, but it doesn't flow off my tongue. > Also, it may be worth explicitly saying that it > doesn't matter how hard to guess a secret the client has nor how good a > MAC algorithm you use with that secret - if anyone can get the secret then > the client is still public. It nearly says that, but not quite and given that > many > developers just don't apparently still think that a hardcoded secret > embedded into a binary is good enough, I'd argue its worth adding a bit more > here. This seems to be cross the line as to what the server defines as confidential, but I'm happy to take text proposals. > - p12/13 in the application profile descriptions - is "resource owner's > device" > correct? That seems to rule out kiosks, which may be correct, but which isn't > obvious. Maybe you mean "device being used by the resource owner" with > no implication as to ownership of the device? Changed to 'the device used by the resource owner' throughout. > - p13 - client application: typos: > > s/such access tokens/such as access tokens/ > > s/which...interact with/with which the application may interact/ Ok. > - p13, "establishing trust with the client or its developer" is badly > phrased, I > think you mean the AS SHOULD NOT just accept the client type unless it has > some external reason to do so. Trusting the developer might be one such. > Being paid is another, and maybe more likely;-) Changed to: The authorization server SHOULD NOT make assumptions about the client type, nor accept the type information provided by the client developer without first establishing trust. > - p13, 2.3 has 2119 language both about the things established at registration > time and things done in the protocol defined here - would it be better to > identify those separately in different sections or maybe move the > registration time stuff into 2.2 with a possible renaming of 2.2. Tweaked a bit, but overall it reads fine to me. > - 3.1.2.1 has a SHOULD for TLS which I think generated a lot of mail on the > list. > I think saying why this is not a MUST would be useful, since it's the kind of > thing that might get revised later on if the situation changes. This specification does not mandate the use of TLS because at the time of this writing, requiring clients to deploy TLS is a significant hurdle for most client developers. > - Figure 3, (p21) has multiple lines labeled A,B & C - saying why might reduce > some confusion. Or maybe, say that the labels reflect rough event timing or > something. It'd also be good if subsequent sections said which parts of fi
Re: [OAUTH-WG] AD Review of -22 (part III)
As before, Thanks S On 21 Jan 2012, at 02:53, Eran Hammer wrote: >> -Original Message- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of Stephen Farrell >> Sent: Thursday, October 13, 2011 10:13 AM > >> Original list of nits: >> -- >> >> - Intro: Maybe add some ascii-art showing the roles of the user, browser, >> client etc. The term client as used here is still commonly confusing and >> especially worth going the extra mile to clarify, before it is first used. >> What I >> think needs to be said early is that what is here called a client is normally >> (running on) a web server. > > Happy to take suggestions, but can't come up with a useful diagram myself. > > Added to the client definition: > > The term client does not imply any particular implementation > characteristics (e.g. whether the application executes on a > server, a desktop, or > other devices). > >> - p4: Maybe s/a string/an octet string/ in the token descriptions, unless the >> access token encoding is constrained to what'd be understood as a string. > > Just a string. > >> - p8: Seems odd to speak of "issuing" an implicit grant - wouldn't that make >> something explicit? Maybe say "With an implicit grant..." >> instead in the 2nd para of 1.3.2? > > Changed to 'When issuing an access token during the implicit grant flow'. > >> - p8: I don't get what "its device operating system" means. Do you mean the >> client is an already-trusted part of the resource owner's device OS? > > Changed to 'the client is part of the device operating system'. > >> - p9 - "Issuing a refresh token is optional" - might be better to say that >> it's the >> authorization server's choice and there's no way for the client to signal a >> request for one. > > Changed to 'Issuing a refresh token is optional at the discretion of the > authorization server.' > >> - p10 - In figure 2, why is the Refresh token shown as optional in step (H) >> but >> not in step (B)? I think it'd be clearer for the figure to reflect the >> protocol >> options and say that the refresh token is optional in (B) as well. > > Because this is the refresh token flow. If it is optional, there is no flow... > >> - p12 - the confidential/public terminology isn't great, did the WG consider >> "authenticating" vs. "non-authenticating"? Trying again to find better terms >> would maybe be worthwhile. > > Didn't try this particular alternative, but it doesn't flow off my tongue. > >> Also, it may be worth explicitly saying that it >> doesn't matter how hard to guess a secret the client has nor how good a >> MAC algorithm you use with that secret - if anyone can get the secret then >> the client is still public. It nearly says that, but not quite and given >> that many >> developers just don't apparently still think that a hardcoded secret >> embedded into a binary is good enough, I'd argue its worth adding a bit more >> here. > > This seems to be cross the line as to what the server defines as > confidential, but I'm happy to take text proposals. > >> - p12/13 in the application profile descriptions - is "resource owner's >> device" >> correct? That seems to rule out kiosks, which may be correct, but which isn't >> obvious. Maybe you mean "device being used by the resource owner" with >> no implication as to ownership of the device? > > Changed to 'the device used by the resource owner' throughout. > >> - p13 - client application: typos: >> >> s/such access tokens/such as access tokens/ >> >> s/which...interact with/with which the application may interact/ > > Ok. > >> - p13, "establishing trust with the client or its developer" is badly >> phrased, I >> think you mean the AS SHOULD NOT just accept the client type unless it has >> some external reason to do so. Trusting the developer might be one such. >> Being paid is another, and maybe more likely;-) > > Changed to: > > The authorization server SHOULD NOT make assumptions about the > client type, nor accept the > type information provided by the client developer without first > establishing trust. > >> - p13, 2.3 has 2119 language both about the things established at >> registration >> time and things done in the protocol defined here - would it be better to >> identify those separately in different sections or maybe move the >> registration time stuff into 2.2 with a possible renaming of 2.2. > > Tweaked a bit, but overall it reads fine to me. > >> - 3.1.2.1 has a SHOULD for TLS which I think generated a lot of mail on the >> list. >> I think saying why this is not a MUST would be useful, since it's the kind of >> thing that might get revised later on if the situation changes. > > This specification does not mandate the use of TLS because at the > time of this writing, requiring clients to deploy TLS is a > significant hurdle for most > client developers
Re: [OAUTH-WG] AD Review of -22 (part II)
I realize that -23 is already published with the below text, but since this is a whole new section and nobody else seemed to bring it up, I wanted to make sure it wasn't missed by the WG. Suggested non-trivial clarifications: - (1) 1.3.4 - "previously arranged" might trigger discusses on the document since it implies that this spec might not be suited for broad use. I think that making it clear that the normal mode for client developers is to work against an existing service (AS and resource server) would help to clarify that such arrangements are ok here. Added new 'Interoperability' section to the introduction: OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, this specification is likely to produce a wide range of non-interoperable implementations. In addition, this specification leaves a few required components partially or fully undefined (e.g. client registration, authorization server capabilities, endpoint discovery). This protocol was design with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability. There is no way to sugar coat reality and hopefully by being blunt about it upfront, we will avoid a prolonged debate about the protocol's failings in that regard. I think it's a good idea to call it out, and I don't want to "sugarcoat" it either, but the phrase "this specification is likely to produce a wide range of non-interoperable implementations" is a bit overdramatic in its tone. Instead, I think we should point to other documents that are being developed explicitly along side of this, such as at the beginning of RFC2904 (http://tools.ietf.org/html/rfc2904). I suggest text like the following instead: OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, this specification does not seek to define all components needed for a fully interoperable deployment within this document. Instead, this specification is intended to work with complimentary documents that define token types [MAC] [Bearer], token formats [JWT] [SAML], client registration [Dynamic Reg?], endpoint discovery [XRD] [SWD], and other considerations. This protocol was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability. -- Justin ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD Review of -22 (part II)
Yes Justin's rewording makes it sound less like non-interoperability is a desired outcome. On 2012-01-26, at 11:06 AM, Justin Richer wrote: > I realize that -23 is already published with the below text, but since this > is a whole new section and nobody else seemed to bring it up, I wanted to > make sure it wasn't missed by the WG. > >>> Suggested non-trivial clarifications: >>> - >>> >>> (1) 1.3.4 - "previously arranged" might trigger discusses on the document >>> since it implies that this spec might not be suited for broad use. I think >>> that >>> making it clear that the normal mode for client developers is to work >>> against >>> an existing service (AS and resource server) would help to clarify that such >>> arrangements are ok here. >> Added new 'Interoperability' section to the introduction: >> >> OAuth 2.0 provides a rich authorization framework with >> well-defined security properties. >> However, as a rich and highly extensible framework with many >> optional components, this >> specification is likely to produce a wide range of >> non-interoperable implementations. >> In addition, this specification leaves a few required components >> partially or fully >> undefined (e.g. client registration, authorization server >> capabilities, endpoint >> discovery). >> >> This protocol was design with the clear expectation that future >> work will define >> prescriptive profiles and extensions necessary to achieve full >> web-scale >> interoperability. >> >> There is no way to sugar coat reality and hopefully by being blunt about it >> upfront, we will avoid a prolonged debate about the protocol's failings in >> that regard. >> > I think it's a good idea to call it out, and I don't want to "sugarcoat" it > either, but the phrase "this specification is likely to produce a wide range > of non-interoperable implementations" is a bit overdramatic in its tone. > Instead, I think we should point to other documents that are being developed > explicitly along side of this, such as at the beginning of RFC2904 > (http://tools.ietf.org/html/rfc2904). I suggest text like the following > instead: > > OAuth 2.0 provides a rich authorization framework with well-defined security > properties. However, as a rich and highly extensible framework with many > optional components, this specification does not seek to define all > components needed for a fully interoperable deployment within this document. > Instead, this specification is intended to work with complimentary documents > that define token types [MAC] [Bearer], token formats [JWT] [SAML], client > registration [Dynamic Reg?], endpoint discovery [XRD] [SWD], and other > considerations. > This protocol was designed with the clear expectation that future work will > define prescriptive profiles and extensions necessary to achieve full > web-scale interoperability. > > > -- Justin > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD Review of -22 (part II)
> -Original Message- > From: Justin Richer [mailto:jric...@mitre.org] > Sent: Thursday, January 26, 2012 6:07 AM > To: Eran Hammer > Cc: OAuth WG > Subject: Re: [OAUTH-WG] AD Review of -22 (part II) > > I realize that -23 is already published with the below text, but since this > is a > whole new section and nobody else seemed to bring it up, I wanted to make > sure it wasn't missed by the WG. > I think it's a good idea to call it out, and I don't want to "sugarcoat" it > either, > but the phrase "this specification is likely to produce a wide range of non- > interoperable implementations" is a bit overdramatic in its tone. Instead, I > think we should point to other documents that are being developed explicitly > along side of this, such as at the beginning of RFC2904 > (http://tools.ietf.org/html/rfc2904). I suggest text like the following > instead: > > OAuth 2.0 provides a rich authorization framework with well-defined security > properties. However, as a rich and highly extensible framework with many > optional components, this specification does not seek to define all > components needed for a fully interoperable deployment within this > document. Instead, this specification is intended to work with complimentary > documents that define token types [MAC] [Bearer], token formats [JWT] > [SAML], client registration [Dynamic Reg?], endpoint discovery [XRD] [SWD], > and other considerations. > This protocol was designed with the clear expectation that future work will > define prescriptive profiles and extensions necessary to achieve full web- > scale interoperability. This does sugarcoat the fact that 2.0 does not provide *any* guaranteed interoperability. The implementations I've seen so far have simply adopted a *profile* of this document along with bearer tokens. We've already seen feedback on this list where client developers were surprised and frustrated with such implementations when trying to reuse code across providers and this is only going to get more noticeable. And then of course we have the insane complexity of the over-architected solutions, adding layer after layer to solve problems that are as simple as making a parameter required and well specified. We've also seen questions about providers looking to claim OAuth 2.0 support while maintaining all their existing architecture and security properties, seeking to push the boundaries of what is permitted by the specification. We've gone to a place where *anything* can be made to look like OAuth. We've seen implementations doing nothing but exchanging SAML assertions for JSON-formatted assertions (or other SAML assertions), without any actual resource owner participation, calling itself OAuth. And sadly, it can. I'm against adding such a laundry list of references. I am also opposed to implying that using these extensions will achieve interoperability because they will not in their current state. The only way to achieve interoperability at this point is by getting rid of most of the optional components (removed or made required), and tightening the definition of others. Or alternatively, come out with a full blown discovery and negotiation protocol - something that would be extremely premature at this point. How can you design a good discovery/negotiation protocol before you have even a partial picture of what it is you want to discovery/negotiate. Instead, I proposing a small tweak (marked with [[ ]]) to the language: --- 1.7. Interoperability OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, [[ on its own, ]] this specification is likely to produce a wide range of non-interoperable implementations. In addition, this specification leaves a few required components partially or fully undefined (e.g. client registration, authorization server capabilities, endpoint discovery). This protocol was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability. --- I can appreciate feeling a little sting from such a disclaimer but we all deserve it for failing to do our job. We took on a successful, simple, narrow, and useful protocol and turned it into mush because after more than 2 years we have failed to find common ground on almost anything that is required to achieve interoperability. Instead we now rely on popular providers such as Facebook and Twitter to set the tone for the rest of the industry, filling in the gaps. My personal frustration is from the fact that a significant number of working group members put the interest of their corporate overlord above what is good for the web. They ha
Re: [OAUTH-WG] AD Review of -22 (part II)
If an app developer writes their own client, than their OAuth code becomes bound in with the code connecting to the underlying resource API which may or may not be standardized. Regardless the tight coupling of OAuth plus an API can only be inter-operable in that specific combination. This will be mitigated through the eventual emergence of client toolkits which keep the resource API and the authorization API cleanly separated. This may lead to further specs and refinements to OAuth2 down the road. But we don't have enough data for that today. IMHO I think for RESTful services, fuzzy interoperability is the nature of the technology for now because of its other benefits. Phil @independentid www.independentid.com phil.h...@oracle.com On 2012-01-26, at 9:49 AM, Eran Hammer wrote: > > >> -Original Message- >> From: Justin Richer [mailto:jric...@mitre.org] >> Sent: Thursday, January 26, 2012 6:07 AM >> To: Eran Hammer >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] AD Review of -22 (part II) >> >> I realize that -23 is already published with the below text, but since this >> is a >> whole new section and nobody else seemed to bring it up, I wanted to make >> sure it wasn't missed by the WG. > >> I think it's a good idea to call it out, and I don't want to "sugarcoat" it >> either, >> but the phrase "this specification is likely to produce a wide range of non- >> interoperable implementations" is a bit overdramatic in its tone. Instead, I >> think we should point to other documents that are being developed explicitly >> along side of this, such as at the beginning of RFC2904 >> (http://tools.ietf.org/html/rfc2904). I suggest text like the following >> instead: >> >> OAuth 2.0 provides a rich authorization framework with well-defined security >> properties. However, as a rich and highly extensible framework with many >> optional components, this specification does not seek to define all >> components needed for a fully interoperable deployment within this >> document. Instead, this specification is intended to work with complimentary >> documents that define token types [MAC] [Bearer], token formats [JWT] >> [SAML], client registration [Dynamic Reg?], endpoint discovery [XRD] [SWD], >> and other considerations. >> This protocol was designed with the clear expectation that future work will >> define prescriptive profiles and extensions necessary to achieve full web- >> scale interoperability. > > This does sugarcoat the fact that 2.0 does not provide *any* guaranteed > interoperability. The implementations I've seen so far have simply adopted a > *profile* of this document along with bearer tokens. We've already seen > feedback on this list where client developers were surprised and frustrated > with such implementations when trying to reuse code across providers and this > is only going to get more noticeable. And then of course we have the insane > complexity of the over-architected solutions, adding layer after layer to > solve problems that are as simple as making a parameter required and well > specified. > > We've also seen questions about providers looking to claim OAuth 2.0 support > while maintaining all their existing architecture and security properties, > seeking to push the boundaries of what is permitted by the specification. > We've gone to a place where *anything* can be made to look like OAuth. We've > seen implementations doing nothing but exchanging SAML assertions for > JSON-formatted assertions (or other SAML assertions), without any actual > resource owner participation, calling itself OAuth. And sadly, it can. > > I'm against adding such a laundry list of references. I am also opposed to > implying that using these extensions will achieve interoperability because > they will not in their current state. The only way to achieve > interoperability at this point is by getting rid of most of the optional > components (removed or made required), and tightening the definition of > others. Or alternatively, come out with a full blown discovery and > negotiation protocol - something that would be extremely premature at this > point. How can you design a good discovery/negotiation protocol before you > have even a partial picture of what it is you want to discovery/negotiate. > > Instead, I proposing a small tweak (marked with [[ ]]) to the language: > > --- > 1.7. Interoperability > > OAuth 2.0 provides a rich authorization framework with well-defined > security properties. However, as a rich and highly extensible > framework with many optional components, [[ on i
Re: [OAUTH-WG] AD Review of -22 (part II)
I really don't see it this way, as a failure. Instead, I think we've managed to successfully scope the document to address important practices and bits of the protocol that will work in tandem with other documents to solve different use cases. One of the biggest problems that we saw coming in from OAuth1.0 was that it tried to be all things to all people all at once, which also didn't help interoperability. I think that what we have is a more composable UNIXy approach here. Namely, OAuth 2 core/framework/whatever does one thing and does it well: it outlines a standard means and structure for getting a token. Does that help you use the token against a web service, do service discovery, pack information into the token itself? No, but it wasn't meant to. It was meant to leave enough space for other docs to take care of that. But I do not think that it's gone so far as to leave a morass of unusable components, much in the way that WS-* did, and I don't think the comparison is a fair one. I think the separations are clean and the usage profiles are clear. By pointing developers to other specifications, most of which are products of this very working group or members of this working group under other umbrellas, we *can* provide a wider view of the world. At the absolute least, I think it needs to point to the two token type docs, and I'd suggest at least keeping the two token format docs as well. And as was pointed out by Phil Hunt, this notion of loosely coupled specs and components is actually *beneficial* to today's web environment. This is another way that this work differs from WS-*: if you're doing one part of WS-*, you're not going to get away without doing the rest of it too if you want to have a working system. As you point out, and somewhat lament, this is not the case with OAuth 2. You can do some parts, and not others, and utalize just the bits that you need. The fact that I can use the same endpoints and mechanisms for user-delegated auth and machine-directed auth is very powerful, and the fact that I can use the same exact client libraries to fetch and use both random-hex tokens and signed JWTs is equally powerful. The fact that I can reuse 90% of that code and also get signed MAC tokens is likewise powerful. Thus, I stand by my originally-suggested text and respectfully submit it to the editor and working group for consideration of inclusion in this section. -- Justin On 01/26/2012 12:49 PM, Eran Hammer wrote: -Original Message- From: Justin Richer [mailto:jric...@mitre.org] Sent: Thursday, January 26, 2012 6:07 AM To: Eran Hammer Cc: OAuth WG Subject: Re: [OAUTH-WG] AD Review of -22 (part II) I realize that -23 is already published with the below text, but since this is a whole new section and nobody else seemed to bring it up, I wanted to make sure it wasn't missed by the WG. I think it's a good idea to call it out, and I don't want to "sugarcoat" it either, but the phrase "this specification is likely to produce a wide range of non- interoperable implementations" is a bit overdramatic in its tone. Instead, I think we should point to other documents that are being developed explicitly along side of this, such as at the beginning of RFC2904 (http://tools.ietf.org/html/rfc2904). I suggest text like the following instead: OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, this specification does not seek to define all components needed for a fully interoperable deployment within this document. Instead, this specification is intended to work with complimentary documents that define token types [MAC] [Bearer], token formats [JWT] [SAML], client registration [Dynamic Reg?], endpoint discovery [XRD] [SWD], and other considerations. This protocol was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web- scale interoperability. This does sugarcoat the fact that 2.0 does not provide *any* guaranteed interoperability. The implementations I've seen so far have simply adopted a *profile* of this document along with bearer tokens. We've already seen feedback on this list where client developers were surprised and frustrated with such implementations when trying to reuse code across providers and this is only going to get more noticeable. And then of course we have the insane complexity of the over-architected solutions, adding layer after layer to solve problems that are as simple as making a parameter required and well specified. We've also seen questions about providers looking to claim OAuth 2.0 support while maintaining all their existing architecture and security properties, seeking to push the boundaries of what is permitted by t
Re: [OAUTH-WG] AD Review of -22 (part II)
The specification already has informative references to the two token types. From purely practical standpoint, I am not adding any more references because that creates more dependencies and longer wait time. There is nothing factually incorrect about the current text. It already makes it clear that additional work is required and expected. It is also a fact that it will produce a wide range an non-interoperable implementations unlike, say, HTTP. We have to make this clear to the reader upfront because every reader outside this WG has exactly the opposite expectation, especially coming from 1.0. I'll make the small tweak proposed below before this goes to the RFC editor, but am not making any other changes to the text unless you can show it is factually incorrect or incomplete. EHL On 1/26/12 1:21 PM, "Justin Richer" wrote: >I really don't see it this way, as a failure. Instead, I think we've >managed to successfully scope the document to address important >practices and bits of the protocol that will work in tandem with other >documents to solve different use cases. One of the biggest problems that >we saw coming in from OAuth1.0 was that it tried to be all things to all >people all at once, which also didn't help interoperability. I think >that what we have is a more composable UNIXy approach here. Namely, >OAuth 2 core/framework/whatever does one thing and does it well: it >outlines a standard means and structure for getting a token. Does that >help you use the token against a web service, do service discovery, pack >information into the token itself? No, but it wasn't meant to. It was >meant to leave enough space for other docs to take care of that. > >But I do not think that it's gone so far as to leave a morass of >unusable components, much in the way that WS-* did, and I don't think >the comparison is a fair one. I think the separations are clean and the >usage profiles are clear. > >By pointing developers to other specifications, most of which are >products of this very working group or members of this working group >under other umbrellas, we *can* provide a wider view of the world. At >the absolute least, I think it needs to point to the two token type >docs, and I'd suggest at least keeping the two token format docs as >well. And as was pointed out by Phil Hunt, this notion of loosely >coupled specs and components is actually *beneficial* to today's web >environment. This is another way that this work differs from WS-*: if >you're doing one part of WS-*, you're not going to get away without >doing the rest of it too if you want to have a working system. As you >point out, and somewhat lament, this is not the case with OAuth 2. You >can do some parts, and not others, and utalize just the bits that you >need. The fact that I can use the same endpoints and mechanisms for >user-delegated auth and machine-directed auth is very powerful, and the >fact that I can use the same exact client libraries to fetch and use >both random-hex tokens and signed JWTs is equally powerful. The fact >that I can reuse 90% of that code and also get signed MAC tokens is >likewise powerful. > >Thus, I stand by my originally-suggested text and respectfully submit it >to the editor and working group for consideration of inclusion in this >section. > > -- Justin > >On 01/26/2012 12:49 PM, Eran Hammer wrote: >> >>> -Original Message- >>> From: Justin Richer [mailto:jric...@mitre.org] >>> Sent: Thursday, January 26, 2012 6:07 AM >>> To: Eran Hammer >>> Cc: OAuth WG >>> Subject: Re: [OAUTH-WG] AD Review of -22 (part II) >>> >>> I realize that -23 is already published with the below text, but since >>>this is a >>> whole new section and nobody else seemed to bring it up, I wanted to >>>make >>> sure it wasn't missed by the WG. >>> I think it's a good idea to call it out, and I don't want to >>>"sugarcoat" it either, >>> but the phrase "this specification is likely to produce a wide range >>>of non- >>> interoperable implementations" is a bit overdramatic in its tone. >>>Instead, I >>> think we should point to other documents that are being developed >>>explicitly >>> along side of this, such as at the beginning of RFC2904 >>> (http://tools.ietf.org/html/rfc2904). I suggest text like the >>>following instead: >>> >>> OAuth 2.0 provides a rich authorization framework with well-defined >>>security >>> properties. However, as a rich and highly extensible framework with >>>many >>> optional components, this specification d
Re: [OAUTH-WG] AD Review of -22 (part II)
I would be unhappy if things were sugarcoated any further. This is definitely a rare specification where OPTIONAL parameters in the API can be REQUIRED by a conforming implmentation (as I discussed in my note on the scope parameter for which the proposed modification does not really change much) I appreciate that there is a cautionary statement that this specification may produce non-interoperable client / server implementations, as I discovered upon writing my first client. The cautionary statement would be invaluable to programmers in the wild who are not used to the unusual semantics of this particular specification. Hence I strongly support (if it counts) keeping the language the way Eran Hammer has suggested. On Fri, Jan 27, 2012 at 5:12 AM, Eran Hammer wrote: > The specification already has informative references to the two token > types. From purely practical standpoint, I am not adding any more > references because that creates more dependencies and longer wait time. > > There is nothing factually incorrect about the current text. It already > makes it clear that additional work is required and expected. It is also a > fact that it will produce a wide range an non-interoperable > implementations unlike, say, HTTP. We have to make this clear to the > reader upfront because every reader outside this WG has exactly the > opposite expectation, especially coming from 1.0. > > I'll make the small tweak proposed below before this goes to the RFC > editor, but am not making any other changes to the text unless you can > show it is factually incorrect or incomplete. > > EHL > > > > On 1/26/12 1:21 PM, "Justin Richer" wrote: > > >I really don't see it this way, as a failure. Instead, I think we've > >managed to successfully scope the document to address important > >practices and bits of the protocol that will work in tandem with other > >documents to solve different use cases. One of the biggest problems that > >we saw coming in from OAuth1.0 was that it tried to be all things to all > >people all at once, which also didn't help interoperability. I think > >that what we have is a more composable UNIXy approach here. Namely, > >OAuth 2 core/framework/whatever does one thing and does it well: it > >outlines a standard means and structure for getting a token. Does that > >help you use the token against a web service, do service discovery, pack > >information into the token itself? No, but it wasn't meant to. It was > >meant to leave enough space for other docs to take care of that. > > > >But I do not think that it's gone so far as to leave a morass of > >unusable components, much in the way that WS-* did, and I don't think > >the comparison is a fair one. I think the separations are clean and the > >usage profiles are clear. > > > >By pointing developers to other specifications, most of which are > >products of this very working group or members of this working group > >under other umbrellas, we *can* provide a wider view of the world. At > >the absolute least, I think it needs to point to the two token type > >docs, and I'd suggest at least keeping the two token format docs as > >well. And as was pointed out by Phil Hunt, this notion of loosely > >coupled specs and components is actually *beneficial* to today's web > >environment. This is another way that this work differs from WS-*: if > >you're doing one part of WS-*, you're not going to get away without > >doing the rest of it too if you want to have a working system. As you > >point out, and somewhat lament, this is not the case with OAuth 2. You > >can do some parts, and not others, and utalize just the bits that you > >need. The fact that I can use the same endpoints and mechanisms for > >user-delegated auth and machine-directed auth is very powerful, and the > >fact that I can use the same exact client libraries to fetch and use > >both random-hex tokens and signed JWTs is equally powerful. The fact > >that I can reuse 90% of that code and also get signed MAC tokens is > >likewise powerful. > > > >Thus, I stand by my originally-suggested text and respectfully submit it > >to the editor and working group for consideration of inclusion in this > >section. > > > > -- Justin > > > >On 01/26/2012 12:49 PM, Eran Hammer wrote: > >> > >>> -Original Message- > >>> From: Justin Richer [mailto:jric...@mitre.org] > >>> Sent: Thursday, January 26, 2012 6:07 AM > >>> To: Eran Hammer > >>> Cc: OAuth WG > >>> Subject: Re: [OAUTH-WG] AD Review of -22 (part II) > >>> &
