[OAUTH-WG] AD review of draft-ietf-oauth-bearer-13

[Stephen Farrell]

Hi,

Good work - another one almost out the door! Thanks.

However, I think this one needs a revised ID before we start
IETF LC. Nothing hard to change I hope, but I think there
are enough changes to make that its best done that way.

I reckon items 3,5,7-11 and 13 below need fixing, but are
I hope all easy. Not sure about item 4.

All my other comments can be considered in conjunction with
whatever other IETF LC comments we get, or now, whichever.

If you want to argue that the WG already had strong consensus
against a change I'm asking for, or that I'm just being dumb,
(which happens all the time:-) then please do that and we can
discuss it on the list and/or at the meeting.

Regards,
Stephen.

questions/comments:

1) What does the 1st sentence of section 2 mean? What is the 2119
MAY for? Couldn't that sentence be deleted? If not, why not?

2) I think you should warn implementers in 2.3 that using the query
string is fairly likely to result in the access token being logged,
which is highly undesirable. (That is there later too, but I think
deserves to be here.) What does "the only feasible method" mean?  I
think that needs to be defined, as was done in 2.2.

3) Where's it say what to do with a scope attribute presented
by a server?

4) What is the realm attribute in section 3? What is a
client expected to do with that? I guess it has to be different
from how realm is used with e.g. Basic. (That might be my
ignorance of HTTP details though;-)

5) Section 3 ABNF allows "realm=foo;realm=bar;scope=baz;error=123"
is that ok? Is processing clear for all cases? I don't think it
is.

6) 3.1, invalid_token - the client MAY retry, SHOULD it do that in
an infinite loop? Probably not;-)

7) "Assuming" token integrity protection is wrong. You need to make
it a MUST. That is, you need to say that resource servers MUST only
accept tokens with strong integrity or similar.

8) I think you need to say that TLS is MTI and MUST be used, (i.e.
with 2119 language) and it'd be better to put that in the
introduction as well as 4.2.

9) As-is 4.2 allows anonymous D-H TLS ciphersuites. I don't think
you want that, but yet you only call for ciphersuites that "offer
confidentiality." I think that needs to be tightened up. 4.3 does
tighten there, but I think 4.2's language also needs fixing.

10) The token validity doesn't have to be "inside." I could e.g.
change a token MAC verification key every hour and limit lifetime
that way.

11) Two paragraphs in 4.2 contradict one another. 3rd last para say
you MUST use TLS, 2nd last para says you MUST have confidentiality
"for instance...TLS." I'd ditch the second one I think, but
something needs fixing.

12) Why reference 2818 instead of 6125?

13) I think you need to say something here about load balancers and
other server side things that terminate TLS, before the resource
server and behind which bearer tokens are unprotected.  At least say
that tokens MUST be protected there and provide guidance as to how
to do that well. Lots of people do that badly I think. (At least at
first;-)

14) Why are cookies first mentioned in 4.3? Seems like that should
have been done earlier.


nits:

abstract: maybe s/granted resources/the associated resources/?

abstract: s/the bearer token needs to/bearer tokens need to/?

1.2: s/abstraction layer/abstraction/ I don't see any layer there

2.1: I (and others) dislike the use of the reference as if it were
part of the sentence, e.g. "defined by [I-D.whatever],..." Better
would be "defined as part of HTTP authentication [I-D.whatever]"
There are multiple occurrences of this.

2.1: s/follows/as follows/

2.1, last para: I think the SHOULD in the last para of 2.1 and the
corresponding rules in 2.2 & 2.3  would be better stated up front.

end of p7, s/attribute MUST NOT/attributes MUST NOT/

4.2, s/recommended/RECOMMENDED/ is better but they mean the same
already!



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AD review of -22

[Eran Hammer-Lahav]

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 draft-ietf-oauth-bearer-13

[Julian Reschke]

On 2011-11-02 17:45, Stephen Farrell wrote:

...
4) What is the realm attribute in section 3? What is a
client expected to do with that? I guess it has to be different
from how realm is used with e.g. Basic. (That might be my
ignorance of HTTP details though;-)
...


Is it different? If it is, it MUST NOT be called "realm".

Best regards, Julian
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Rechartering JSON based request.

[Torsten Lodderstedt]

Hi,

standard OAuth does not sign request parameters. Does this mean OAuth 
itself is not secure enough? Or is there a new threat angle against 
those parameters in the contect of Connect?


regards,
Torsten.

Am 27.10.2011 22:24, schrieb George Fletcher:
The main reason to include the OAuth parameters in the request is to 
ensure that the request object was not modified in transit since the 
JSON request object can be signed. Agreed that it would be simpler if 
OAuth adopted the JSON request style.


Thanks,
George

On 10/27/11 1:33 PM, tors...@lodderstedt.net wrote:

Hi John,

why do you need to include the OAuth request parameters into the JSON 
document? I would expect OpenId Connect to extend OAuth 
none-intrusively. This would mean to use the JSON document for OpenId 
connect specific parameters only. Alternatively, the JSON request 
style could be adopted as part of OAuth. Then, the URI request 
parameters could be omitted.


regards,
Torsten.

Gesendet mit BlackBerry® Webmail von Telekom Deutschland


*From: * John Bradley 
*Date: *Thu, 27 Oct 2011 13:52:31 -0300
*To: *Torsten Lodderstedt
*Cc: *Nat Sakimura; OAuth WG
*Subject: *Re: [OAUTH-WG] Rechartering JSON based request.

Hopefully to make it more compatible with existing OAuth 2 libraries. 
   At least leave open the possibility of dealing with it at a higher 
level.


The argument has been made that you probably need to modify the 
library anyway to check that the duplicate parameters are a match.


If there is consensus that the parameters should only be in the JSON 
then we would happily not duplicate them.


It is mostly a case of trying to fit in to the existing OAuth work 
and libraries.


John B.

On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote:


why is it neccessary to duplicate the OAuth request parameters?

Am 27.10.2011 00:31, schrieb John Bradley:

Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.

It is essentially  a standardization of the method we are using in 
openID Connect to make signed requests to the Authorization server.


We do have the issue that parameters in the signed/encrypted 
request necessarily duplicate the query parameters to keep it a 
valid OAuth request plus an extension.


Even if it doesn't wind up as a OAuth WG item it is probably worth 
people looking at it before the final openID spec is voted on.


Regards
John B.

On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote:


Hi Nat,

I think your proposal would be a useful OAuth enhancement. A 
JSON-based request format would allow for more complex requests 
(e.g. carrying resource server URLs and corresponding scope values 
;-)).


Please note: I also think the way this mechanism is introduced and 
used in the current OpenID connect spec requires OpenID connect 
clients and servers to handle OAuth request parameters differently 
than for standard OAuth requests. Introducing the JSON based claim 
request capability to OAuth would be a way to cope with this.


regards,
Torsten.

Am 22.10.2011 16:00, schrieb Nat Sakimura:

Hi.

Just a clarification:

Although my expired draft is 'request by reference', what was 
proposed through it at the iiw really is a generalized JSON based 
claim request capability. It could be passed by value as JSON or 
could be passed by reference. The later is an optimization for 
bandwidth constrained network as well as strengthening security 
in some ways. This capability already exists in OpenID Connect 
but it is actually an underpinning transport, so it probably 
should belong to OAuth instead. This was the primary reason for 
the proposal.


Nat

On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:


Hi all,

my prioritization is driven by the goal to make OAuth the
authorization framework of choice for any internet standard
protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first
explain what is missing from my point of view and explain
some thoughts how to fill the gaps.

A standard protocol is defined in terms of resource types and
messages by a body (e.g. IETF, OIDF, OMA), (hopefully)
implemented in many places, and used by different but
deployment-independent clients. OAuth-based protocol
specifications must also define scope values (e.g. read,
write, send) and their relation to the resource types and
messages. The different deployments expose the standard
protocol on different resource server endpoints. In my
opinion, it is fundamental to clearly distinguish scope
values (standardized, static) and  resource server addresses
(deployment specific) and to manage their relationships. The
current scope definition is much to weak and insufficient.
Probably, the UMA concepts of hosts, resources sets, and
corresponding scopes could be adopted for that purpose.

OAuth today requires clients to register with the

Re: [OAUTH-WG] AD review of -22

[Torsten Lodderstedt]

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] Rechartering JSON based request.

[John Bradley]

In the general OAuth case the user doesn't have much incentive to modify the 
request parameters.

In Connect the user is also authenticating to the client.  There may be cases 
where the user attempts to modify the request to escalate privileges.

I suspect state might be something someone would look at modifying depending on 
what the RP is passing.

Things that are Connect specific like authentication context requests need to 
be signed,  so signing the other parts at the same time is not a big deal.

When FICAM looks at OAUTH 2.0 to replace SAML attribute query,  I am betting 
someone is going to be looking for signed requests,m based on defence ion depth 
even if there are know obvious attacks.

John B.
On 2011-11-02, at 4:32 PM, Torsten Lodderstedt wrote:

> Hi,
> 
> standard OAuth does not sign request parameters. Does this mean OAuth itself 
> is not secure enough? Or is there a new threat angle against those parameters 
> in the contect of Connect?
> 
> regards,
> Torsten.
> 
> Am 27.10.2011 22:24, schrieb George Fletcher:
>> 
>> The main reason to include the OAuth parameters in the request is to ensure 
>> that the request object was not modified in transit since the JSON request 
>> object can be signed. Agreed that it would be simpler if OAuth adopted the 
>> JSON request style.
>> 
>> Thanks,
>> George
>> 
>> On 10/27/11 1:33 PM, tors...@lodderstedt.net wrote:
>>> 
>>> Hi John,
>>> 
>>> why do you need to include the OAuth request parameters into the JSON 
>>> document? I would expect OpenId Connect to extend OAuth none-intrusively. 
>>> This would mean to use the JSON document for OpenId connect specific 
>>> parameters only. Alternatively, the JSON request style could be adopted as 
>>> part of OAuth. Then, the URI request parameters could be omitted.
>>> 
>>> regards,
>>> Torsten.
>>> Gesendet mit BlackBerry® Webmail von Telekom Deutschland
>>> 
>>> From: John Bradley 
>>> Date: Thu, 27 Oct 2011 13:52:31 -0300
>>> To: Torsten Lodderstedt
>>> Cc: Nat Sakimura; OAuth WG
>>> Subject: Re: [OAUTH-WG] Rechartering JSON based request.
>>> 
>>> Hopefully to make it more compatible with existing OAuth 2 libraries.At 
>>> least leave open the possibility of dealing with it at a higher level.
>>> 
>>> The argument has been made that you probably need to modify the library 
>>> anyway to check that the duplicate parameters are a match.
>>> 
>>> If there is consensus that the parameters should only be in the JSON then 
>>> we would happily not duplicate them.
>>> 
>>> It is mostly a case of trying to fit in to the existing OAuth work and 
>>> libraries.
>>> 
>>> John B.
>>> 
>>> On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote:
>>> 
 why is it neccessary to duplicate the OAuth request parameters?
 
 Am 27.10.2011 00:31, schrieb John Bradley:
> 
> Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.
> 
> It is essentially  a standardization of the method we are using in openID 
> Connect to make signed requests to the Authorization server.
> 
> We do have the issue that parameters in the signed/encrypted request 
> necessarily duplicate the query parameters to keep it a valid OAuth 
> request plus an extension.
> 
> Even if it doesn't wind up as a OAuth WG item it is probably worth people 
> looking at it before the final openID spec is voted on.
> 
> Regards
> John B.
> 
> On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote:
> 
>> Hi Nat,
>> 
>> I think your proposal would be a useful OAuth enhancement. A JSON-based 
>> request format would allow for more complex requests (e.g. carrying 
>> resource server URLs and corresponding scope values ;-)). 
>> 
>> Please note: I also think the way this mechanism is introduced and used 
>> in the current OpenID connect spec requires OpenID connect clients and 
>> servers to handle OAuth request parameters differently than for standard 
>> OAuth requests. Introducing the JSON based claim request capability to 
>> OAuth would be a way to cope with this.
>> 
>> regards,
>> Torsten.
>> 
>> Am 22.10.2011 16:00, schrieb Nat Sakimura:
>>> 
>>> Hi. 
>>> 
>>> Just a clarification: 
>>> 
>>> Although my expired draft is 'request by reference', what was proposed 
>>> through it at the iiw really is a generalized JSON based claim request 
>>> capability. It could be passed by value as JSON or could be passed by 
>>> reference. The later is an optimization for bandwidth constrained 
>>> network as well as strengthening security in some ways. This capability 
>>> already exists in OpenID Connect but it is actually an underpinning 
>>> transport, so it probably should belong to OAuth instead. This was the 
>>> primary reason for the proposal. 
>>> 
>>> Nat
>>> 
>>> On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt 
>>>  wrote:
>>> H

Re: [OAUTH-WG] AD review of -22

[John Bradley]

+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

[Eran Hammer-Lahav]

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

Re: [OAUTH-WG] AD review of -22

[Phil Hunt]

+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

[Justin Richer]

+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

[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

[Mike Jones]

+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

[Stephen Farrell]

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

[John Bradley]

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

[Phillip Hunt]

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

[Stephen Farrell]

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

[Torsten Lodderstedt]

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

[Eran Hammer-Lahav]

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-WG] Authentication Methods

[Elliot Cameron]

What are some common or suggested authentication methods that are used in 
conjunction with OAuth 2.0? 
Is TLS/SSL the only standard one or do people normally roll their own 
authentication within OAuth's flows? 




Elliot Cameron 
Covenant Eyes Software Developer 
elliot.came...@covenanteyes.com 
810-771-8322 

Call 810-771-8322 


Phone to call with 

Covenant Eyes 








Connect 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AD review of -22

[John Bradley]

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] Authentication Methods

[Justin Richer]

Please clarify what you're asking, if you would: There are two kinds of
authentication which happen with OAuth: client authentication and user
authentication, and neither of which are standardized on two-way TLS. 

Client authentication happens at the token endpoint and is described in
section 2.3, which recommends use of HTTP Basic but allows for form
parameters or other, out-of-scope methods such as client assertions. 

User authentication happens at the authorization endpoint and is
completely outside of the scope of OAuth (by design). You can use
whatever means you like to authenticate the user here, from a local
username/password, OpenID, SAML, NTLM, whatever. OAuth makes no
assumptions about how that happens and makes no recommendations, either.

 -- Justin

On Wed, 2011-11-02 at 16:59 -0400, Elliot Cameron wrote:
> What are some common or suggested authentication methods that are used
> in conjunction with OAuth 2.0?
> Is TLS/SSL the only standard one or do people normally roll their own
> authentication within OAuth's flows?
> 
> Elliot Cameron
> 
> Covenant Eyes Software Developer
> 
> elliot.came...@covenanteyes.com
> 
> 810-771-8322
> 
> 
> Call 810-771-8322
> Phone to call with
> Covenant Eyes
> 
>  
>  
> Connect
> 
> 
> ___
> 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] Authentication Methods

[John Bradley]

That probably depends on what authentication you are asking about.

Authentication of the client to the protected resource has two profiles MAC & 
Bearer.
Authentication of the client to the Token Endpoint has an example in the OAuth 
spec using client_id and a symmetric secret.
That is extensible and openID Connect defines an additional method using 
asymmetric keys.

Authentication of the resource owner to the authorization server is roll your 
own:)

Authentication of the Authorization server/token endpoint/protected resource to 
the client is TLS for the most part.

Regards
John B.
On 2011-11-02, at 5:59 PM, Elliot Cameron wrote:

> What are some common or suggested authentication methods that are used in 
> conjunction with OAuth 2.0?
> Is TLS/SSL the only standard one or do people normally roll their own 
> authentication within OAuth's flows?
> 
> Elliot Cameron
> Covenant Eyes Software Developer
> elliot.came...@covenanteyes.com
> 810-771-8322
> 
> ___
> 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] Phishing with Client Application Name Spoofing

[Torsten Lodderstedt]

Hi Andre,

how do you think differs the threat you descibed from 
http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-4.4.1.4?


regards,
Torsten.
Am 26.10.2011 22:44, schrieb André DeMarre:

Should a brief explanation of this be added to the Threat Model and
Security Considerations document? Or does anyone even agree that this
can be a problem?

Regards,
Andre DeMarre

On Tue, Oct 4, 2011 at 11:32 AM, André DeMarre  wrote:

I've not seen this particular variant of phishing and client
impersonation discussed. A cursory search revealed that most of the
related discussion centers around either (a) client impersonation with
stolen client credentials or (b) phishing by malicious clients
directing resource owners to spoofed authorization servers. This is
different.

This attack exploits the trust a resource owner has for an OAuth
authorization server so as to lend repute to a malicious client
pretending to be from a trustworthy source. This is not necessarily a
direct vulnerability of OAuth; rather, it shows that authorization
servers have a responsibility regarding client application names and
how they present resource owners with the option to allow or deny
authorization.

A key to this exploit is the process of client registration with the
authorization server. A malicious client developer registers his
client application with a name that appears to represent a legitimate
organization which resource owners are likely to trust. Resource
owners at the authorization endpoint may be misled into granting
authorization when they see the authorization server asserting "  is requesting permission to..."

Imagine someone registers a client application with an OAuth service,
let's call it Foobar, and he names his client app "Google, Inc.". The
Foobar authorization server will engage the user with "Google, Inc. is
requesting permission to do the following." The resource owner might
reason, "I see that I'm legitimately on the https://www.foobar.com
site, and Foobar is telling me that Google wants permission. I trust
Foobar and Google, so I'll click Allow."

To make the masquerade act even more convincing, many of the most
popular OAuth services allow app developers to upload images which
could be official logos of the organizations they are posing as. Often
app developers can supply arbitrary, unconfirmed URIs which are shown
to the resource owner as the app's website, even if the domain does
not match the redirect URI. Some OAuth services blindly entrust client
apps to customize the authorization page in other ways.

This is hard to defend against. Authorization server administrators
could police client names, but that approach gives them a burden
similar to certificate authorities to verify organizations before
issuing certificates. Very expensive.

A much simpler solution is for authorization servers to be careful
with their wording and educate resource owners about the need for
discretion when granting authority. Foobar's message above could be
changed: "An application calling itself Google, Inc. is requesting
permission to do the following" later adding, "Only allow this request
if you are sure of the application's source." Such wording is less
likely to give the impression that the resource server is vouching for
the application's identity.

Authorization servers would also do well to show the resource owner
additional information about the client application to help them make
informed decisions. For example, it could display all or part of the
app's redirect URI, saying, "The application is operating on
example.com" or "If you decide to allow this application, your browser
will be directed to http://www.example.com/."; Further, if the client
app's redirect URI uses TLS (something authorization servers might
choose to mandate), then auth servers can verify the certificate and
show the certified organization name to resource owners.

This attack is possible with OAuth 1, but OAuth 2 makes successful
exploitation easier. OAuth 1 required the client to obtain temporary
credentials (aka access tokens) before sending resource owners to the
authorization endpoint. Now with OAuth 2, this attack does not require
resource owners to interact with the client application before
visiting the authorization server. The malicious client developer only
needs to distribute links around the web to the authorization server's
authorization endpoint. If the HTTP service is a social platform, the
client app might distribute links using resource owners' accounts with
the access tokens it has acquired, becoming a sort of worm. Continuing
the Google/Foobar example above, it might use anchor text such as "I
used Google Plus to synchronize with my Foobar account." Moreover, if
the app's redirect URI bounces the resource owner back to the HTTP
service after acquiring an authorization code, the victim will never
see a page rendered at the insidious app's domain.

This is especially dangerous because the public is not trained

[OAUTH-WG] small typo in core draft 22

[nov matake]

If it's already reported, my apologies.

In section 8.4, "If a response type contains one of more space characters".
It should be "one or more".

Thanks

--
nov matake
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AD review of -22

[André DeMarre]

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

[William Mills]

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 draft-ietf-oauth-bearer-13

[Manger, James H]

> 5) Section 3 ABNF allows "realm=foo;realm=bar;scope=baz;error=123"
> is that ok? Is processing clear for all cases? I don't think it
> is.


The ABNF does not allow that.
It requires commas as separators, not semi-colons.
It requires double quotes around values.
The only possible ambiguity in this example is the duplicate realms, but that 
parameter isn't even defined in this spec (it is defined in 
draft-ietf-httpbis-p7-auth)! I guess that spec could try to explicitly define 
behaviour in the case of this particular error, but it may have to explicitly 
describe a lot of other error cases as well.

--
James Manger
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth