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.hunt@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:jricher@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 <eran@hueniverse.com>
>>> To: John Bradley <ve7jtb@ve7jtb.com>; Torsten Lodderstedt
>>> <torsten@lodderstedt.net>
>>> Cc: "oauth@ietf.org" <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-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of
>>> John Bradley [ve7jtb@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