Subject: [OAUTH-WG] What needs to be done to complete MAC

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 26 Nov 2012 18:15:15 +0000

Hi

What needs to be done to complete the MAC token spec ? Without having it 
signed off it will be difficult to get people working with OAuth 1.0 
convinced to move to 2.0.
I'm seeing another user request for getting OAuth 1.0 support extended 
further because the user expects it is more secure, and I guess because 
it is proven to work for people, and I guess because many OAuth 1.0 
users feel that should stay from OAuth 2.0 because of some bad press.

Without MAC being completed the division will continue, with even more 
misleading anti-OAuth2 posts appearing (though I guess some of the 
better posts point to some level of complexity in 2.0).

Is it a matter of a security expert validating the text, fixing few 
typos, and basically signing it off ?

If someone is interested then I can provide the info offline on how it 
MAC supported in our framework to get things tested easily and such...

Cheers, Sergey

---

From: Phil Hunt <[email-masked]>
Date: Mon, 26 Nov 2012 10:28:12 -0800

If we want to get this done we have to get agreements on the requirements for HOK. Several meetings ago (quebec) the group indicated that mac wasn't appropriate to anyone's needs. 

Some would argue that OAuth1 users arguably have less security than the simpler bearer token /tls model in OAuth2. This just shows the real issue of demonstrated need has not been properly defined and understood. 

More dialog on use cases is very helpful to moving HOK/MAC/etc forward. 

Phil

On 2012-11-26, at 10:15, Sergey Beryozkin <[email-masked]> wrote:

> Hi
> 
> What needs to be done to complete the MAC token spec ? Without having it signed off it will be difficult to get people working with OAuth 1.0 convinced to move to 2.0.
> I'm seeing another user request for getting OAuth 1.0 support extended further because the user expects it is more secure, and I guess because it is proven to work for people, and I guess because many OAuth 1.0 users feel that should stay from OAuth 2.0 because of some bad press.
> 
> Without MAC being completed the division will continue, with even more misleading anti-OAuth2 posts appearing (though I guess some of the better posts point to some level of complexity in 2.0).
> 
> Is it a matter of a security expert validating the text, fixing few typos, and basically signing it off ?
> 
> If someone is interested then I can provide the info offline on how it MAC supported in our framework to get things tested easily and such...
> 
> Cheers, Sergey
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: William Mills <[email-masked]>
Date: Mon, 26 Nov 2012 10:41:35 -0800 (PST)

I object to tying MAC to HOK, I see them as independent and I frankly don't understand why folks insist that MAC can not proceed without a broader HOK spec.  

-bill

________________________________
 From: Phil Hunt <[email-masked]>
To: Sergey Beryozkin <[email-masked]> 
Cc: "<[email-masked]>" <[email-masked]> 
Sent: Monday, November 26, 2012 10:28 AM
Subject: Re: [OAUTH-WG] What needs to be done to complete MAC

Phil

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 26 Nov 2012 18:45:26 +0000

I agree that HOK may be independent of MAC and should be a separate issue, as MAC does not solve my proof of possession for a HOK solution

From: [email-masked] [mailto:[email-masked]] On Behalf Of William Mills
Sent: Monday, November 26, 2012 10:42 AM
To: Phil Hunt; Sergey Beryozkin
Cc: <[email-masked]>
Subject: Re: [OAUTH-WG] What needs to be done to complete MAC

-bill

________________________________
From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
To: Sergey Beryozkin <[email-masked]<mailto:[email-masked]>>
Cc: "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Sent: Monday, November 26, 2012 10:28 AM
Subject: Re: [OAUTH-WG] What needs to be done to complete MAC

Phil

On 2012-11-26, at 10:15, Sergey Beryozkin <[email-masked]<mailto:[email-masked]>> wrote:

> [email-masked]<mailto:[email-masked]>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Mon, 26 Nov 2012 13:46:00 -0500

I agree with Bill's statement and have stated so on several occasions. I 
think it's clear that we've got several use cases that are interested in 
different things, and I think that there's very little chance that we're 
going to have one super amazing specification that can cover all of 
them. I think we're going to end up with several different kinds of 
tokens with different properties, and we should work on them 
independently, openly, and in parallel.

It was decided at IETF85 that we should put together a regular 
discussion to help decide the fate of MAC, HOK, and other similar 
efforts. For those interested in the discussion, Hannes is setting up a 
series of phone conversations about this very topic:

http://www.doodle.com/smvh5pmcqc43dti3#table

  -- Justin

On 11/26/2012 01:41 PM, William Mills wrote:
> I object to tying MAC to HOK, I see them as independent and I frankly 
> don't understand why folks insist that MAC can not proceed without a 
> broader HOK spec.
>
> -bill
>
> ------------------------------------------------------------------------
> *From:* Phil Hunt <[email-masked]>
> *To:* Sergey Beryozkin <[email-masked]>
> *Cc:* "<[email-masked]>" <[email-masked]>
> *Sent:* Monday, November 26, 2012 10:28 AM
> *Subject:* Re: [OAUTH-WG] What needs to be done to complete MAC
>
> If we want to get this done we have to get agreements on the 
> requirements for HOK. Several meetings ago (quebec) the group 
> indicated that mac wasn't appropriate to anyone's needs.
>
> Some would argue that OAuth1 users arguably have less security than 
> the simpler bearer token /tls model in OAuth2. This just shows the 
> real issue of demonstrated need has not been properly defined and 
> understood.
>
> > What needs to be done to complete the MAC token spec ? Without 
> having it signed off it will be difficult to get people working with 
> OAuth 1.0 convinced to move to 2.0.
> > I'm seeing another user request for getting OAuth 1.0 support 
> extended further because the user expects it is more secure, and I 
> guess because it is proven to work for people, and I guess because 
> many OAuth 1.0 users feel that should stay from OAuth 2.0 because of 
> some bad press.
> >
> > Without MAC being completed the division will continue, with even 
> more misleading anti-OAuth2 posts appearing (though I guess some of 
> the better posts point to some level of complexity in 2.0).
> >
> > If someone is interested then I can provide the info offline on how 
> it MAC supported in our framework to get things tested easily and such...
> >
> > Cheers, Sergey
> >
> > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Nov 2012 21:01:38 +0200

Hi Sergey, 

as Phil said it would be helpful for us to receive reviews of this document:
http://tools.ietf.org/html/draft-tschofenig-oauth-security-00

The document lists requirements and threats. 

Ciao
Hannes

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 27 Nov 2012 11:15:36 +0000

Hi
> Some would argue that OAuth1 users arguably have less security than the simpler bearer token /tls model in OAuth2. This just shows the real issue of demonstrated need has not been properly defined…

 From my point of view, the issue is not about which model is considered 
to be more secure but about showing the OAuth1 users which have accepted 
and accustomed to having the clients signing their token & protected 
resource requests by following a well-understood signature algorithm 
that by working with MAC they can effectively get the same with OAuth 
2.0 and with the lesser implementation (and roundtrip) cost,

IMHO this further support for encouraging 1.0 users to migrate by having 
also MAC done (in addition to dropping a temporarily request token 
requirement) is not necessarily a high-priority issue for the major 
OAuth 2.0 providers who offer a support for large-scale 2.0 deployments 
and such.

It is though more important for the frameworks like the one I'm working 
upon, which target a smaller scale, simpler OAuth2 applications. well we 
support OAuth 1.0 and we support the latest MAC draft, but the 
'signature' effect is massive and hence I'm hoping MAC spec can be 
completed without having all the OAuth2.0 experts agreeing on its virtues...

Thanks, Sergey

> On 2012-11-26, at 10:15, Sergey Beryozkin<[email-masked]>  wrote:
>
>> Hi
>>

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 27 Nov 2012 11:23:24 +0000

Hi Hannes
> The document lists requirements and threats.

Let me offer two possibly naive reasons why using MAC may help, one of 
them is related to the security, another to the ease of HOK support on 
the client

1. The most safe way to return MAC token to the client is to use a 
two-way TLS due to the mac key also returned to the client. Two-Way TLS 
offers a stronger support for getting the client authenticated along the 
way too

2. Assuming HOK confirmation matters at all (and I believe it does), 
IMHO it is much simpler for a basic client implementation to apply a MAC 
signature algo and thus work with the OAuth2 servers expecting HOK 
confirmations

One more reason is more about facilitating the further migration to 2.0 
which I tried to outline in my response to Phil Hunt

Thanks, Sergey

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 27 Nov 2012 14:33:05 +0200

Hi Sergey, 

I believe we would make faster progress on security topics if could
focus on listing security requirements we have and what threats we want
to mitigate. The reason why we have not finished this topic is simply
because everyone was just talking about specific (but incomplete)
solutions. You are unfortunately falling in the same trap as well. 

If you really care about the topic then have a look at the mentioned
document and tell us whether the requirements are complete. 
Reading through the document you will notice that there a few more
considerations to pay attention to than just the few listed below. 

Ciao
Hannes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Sergey Beryozkin
> Sent: Tuesday, November 27, 2012 1:23 PM
> To: Hannes Tschofenig
> Cc: <[email-masked]>
indicated
> that mac wasn't appropriate to anyone's needs.
> >>
real
> issue of demonstrated need has not been properly defined and
understood.
> extended further because the user expects it is more secure, and I
guess
> because it is proven to work for people, and I guess because many
OAuth
> 1.0 users feel that should stay from OAuth 2.0 because of some bad
press.
> more misleading anti-OAuth2 posts appearing (though I guess some of
the

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 27 Nov 2012 12:45:08 +0000

Hi Hannes

> solutions. You are unfortunately falling in the same trap as well.

Quite possible - I was hoping to give some perspective of someone who 
would like to see a wider acceptance of 2.0 at the grass root level if 
you wish where 'grass root' represents simple 2.0 applications.

> considerations to pay attention to than just the few listed below.
Believe it or not I did read the document awhile back :-) and will 
definitely read it few times more - it is a must-read. I'm just 
concerned that it appears that the possible progress on MAC
needs to be justified by linking it implicitly to the security threats 
doc. And I'm not sure it is the best way to follow.

How about a slightly different approach.
Do you agree that supporting HOK is important ? Assuming yes then I 
guess the threats doc must be talking about the relevant issues that HOK 
can help with addressing.

If we can agree on this then IMHO MAC passes the acceptance criteria 
because it offers one way to provide a HOK support. Whether JWT or other 
token type may also help with HOK support is entirely different issue 
and it is down to specific OAuth2 implementers on which HOK-capable 
token to support

Thanks, Sergey

>> Cc:<[email-masked]>

---

From: William Mills <[email-masked]>
Date: Tue, 27 Nov 2012 09:32:49 -0800 (PST)

I don't see in that document a significant use case for a signed token, which is use over clear text channels.  Bearer tokens have similar security properties to HTTP cookies (minus for the moment the XSRF problem).  Signed token types can be used over plain text channels without the concern about re-use of the token by a 3rd party.  Replay protection is still needed but that's not in scope for the token mechanism itself.

It's always been this simple use case that has been my focus for MAC.

Flickr uses OAuth 1.0a today over HTTP and will for many years to come, we won't be able to go completely SSL due to the installed base of clients.  Given the dynamic I see in the mobile development community I don't see us getting all mobile apps into SSL only anytime soon.  MAC and OAuth 1.0 solve the token security problem for the last hop to the phone/wi-fi device without SSL for the bulk of the application traffic.

-bill

________________________________
 From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
To: ext Sergey Beryozkin <[email-masked]>; Hannes Tschofenig <[email-masked]> 
Cc: [email-masked] 
Sent: Tuesday, November 27, 2012 4:33 AM
Subject: Re: [OAUTH-WG] What needs to be done to complete MAC
 
Hi Sergey, 

Ciao
Hannes

indicated
real
understood.
guess
OAuth
press.
the

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 27 Nov 2012 17:51:17 +0000

An important point to note, that many OAuth1 implementations in the wild screw up, is that you still need TLS between the client and the Authorization Server to protect the token and secret in transit, even if you don't use TLS during the client's calls to the protected resource. Since OAuth2 core mandates TLS at the Token Endpoint explicitly for all token types, that's much more clear to understand (in my opinion) in implementation.

In case the above is unclear, what I'm trying to say is this: putting a signed token like MAC into the OAuth2 framework will give us the capability of OAuth1 in a clearer, more secure (in the wild) structure. I think it's vitally important that we have this functionality, and while I understand the need for clear use cases, I don't understand the feet-dragging.

 -- Justin

On Nov 27, 2012, at 12:32 PM, William Mills wrote:

-bill

________________________________
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]<mailto:[email-masked]>>
To: ext Sergey Beryozkin <[email-masked]<mailto:[email-masked]>>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Sent: Tuesday, November 27, 2012 4:33 AM
Subject: Re: [OAUTH-WG] What needs to be done to complete MAC

Hi Sergey,

Ciao
Hannes

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of ext Sergey Beryozkin
> Cc: <[email-masked]<mailto:[email-masked]>>
indicated
real
understood.
> >> On 2012-11-26, at 10:15, Sergey Beryozkin<[email-masked]<mailto:[email-masked]>>
> wrote:
> >>
> >>> Hi
> >>>
guess
OAuth
press.
the

---

From: William Mills <[email-masked]>
Date: Tue, 27 Nov 2012 09:59:16 -0800 (PST)

Yes!

The other thing that is better in the OAuth 2 model is the refresh capability, which makes plain text channel token usage more palatable.

________________________________
 From: "Richer, Justin P." <[email-masked]>
To: William Mills <[email-masked]> 
Cc: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>; ext Sergey Beryozkin <[email-masked]>; Hannes Tschofenig <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Tuesday, November 27, 2012 9:51 AM
Subject: Re: [OAUTH-WG] What needs to be done to complete MAC

 -- Justin

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2012 20:50:36 +0200

Hi Sergey, 

On Nov 27, 2012, at 2:45 PM, Sergey Beryozkin wrote:

> Quite possible - I was hoping to give some perspective of someone who would like to see a wider acceptance of 2.0 at the grass root level if you wish where 'grass root' represents simple 2.0 applications.

We are obviously interested in wide acceptance of our specifications. 

> Believe it or not I did read the document awhile back :-)

Cool. Thanks. 

> and will definitely read it few times more - it is a must-read. I'm just concerned that it appears that the possible progress on MAC
> needs to be justified by linking it implicitly to the security threats doc. And I'm not sure it is the best way to follow.
> 
> Do you agree that supporting HOK is important ? Assuming yes then I guess the threats doc must be talking about the relevant issues that HOK can help with addressing.
> 
> If we can agree on this then IMHO MAC passes the acceptance criteria because it offers one way to provide a HOK support. Whether JWT or other token type may also help with HOK support is entirely different issue and it is down to specific OAuth2 implementers on which HOK-capable token to support

In Section 4 of http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 we tried to explain that there are three approaches to address very common security threats that exist in these three party protocols. All three approach, namely "confidentiality protection", "sender constraint", and "key confirmation", address these common threats in their own way. The details vary between the different solution categories. We published the bearer token specification, which follows the approach described in Section 4.1 ("confidentiality protection"). 

The group very early on said that they also wand an alternative, using "key confirmation". This was actually the reason why we moved the bearer and the MAC specification out of the main OAuth 2.0 and put them into separate documents. Consequently, there is no need to convince us that we should be working on a solution that is different than the bearer token (even I keep explaining folks that bearer tokens are not cookies and that they have similar properties than the other mechanisms). 

We had also figured out that there isn't only a single solution that will make everyone happy. But we also don't want to standardize everything comes to our mind: you can see in other areas (e.g., EAP, SASL, TLS ciphersuites, IKEv2 extension, etc.) that the creativity is endless when it comes to authentication and key exchange protocols. 

I am hoping that the conference calls (which I had asked folks to indicate their preference for) will help us to come up with an answer of what the essential requirements are (and hopefully within a very short timeframe). You are, btw, welcome to join those calls. 

Ciao
Hannes

PS: We should have probably never used the term HOK since it caused more confusion than it helped.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2012 20:54:48 +0200

Hi Bill, 

On Nov 27, 2012, at 7:32 PM, William Mills wrote:

> I don't see in that document a significant use case for a signed token, which is use over clear text channels.

With "that document" I guess you refer to http://tools.ietf.org/html/draft-tschofenig-oauth-security-00? 

With "signed token" do you mean an access token that is signed by the party issuing it? 

>  Bearer tokens have similar security properties to HTTP cookies (minus for the moment the XSRF problem).

Please don't compare bearer tokens with cookies. They are very different. 

>  Signed token types can be used over plain text channels without the concern about re-use of the token by a 3rd party.  Replay protection is still needed but that's not in scope for the token mechanism itself.

I guess signed token here means something like MAC where you actually do not sign the token but compute a message digest over some headers of the request. 
> It's always been this simple use case that has been my focus for MAC.
Could you describe your simple use case? For example, is it acceptable for you to use TLS from the client to the authorization server to get the MAC key (and algorithm)? What is your story regarding computing the keyed message digest over the HTTP message: header fields only, body? What about confidentiality protection? What about protecting the actual data (not just the request that contains the access token)?

> 
> Flickr uses OAuth 1.0a today over HTTP and will for many years to come, we won't be able to go completely SSL due to the installed base of clients.

If that's the case and they only use HTTP then they are in violation of the OAuth 1.0a spec. 

>  Given the dynamic I see in the mobile development community I don't see us getting all mobile apps into SSL only anytime soon.

What makes you believe that guys who don't want to use an off-the-shelf library for security will get a custom security solution right. 
The performance of TLS is not an issue for mobile devices anymore. It may have been an issue in 2005. 

If they want to use OAuth 2.0 (as it is specified today; irrespectively of the bearer token spec) they have to use TLS in their code base. 

>  MAC and OAuth 1.0 solve the token security problem for the last hop to the phone/wi-fi device without SSL for the bulk of the application traffic.
The IETF OAuth 1.0a specification requires TLS to be used between the client and the authorization server. 

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2012 20:54:56 +0200

Good that you both raise this point. The refresh token mechanism allows us to request new access tokens (and new keying material correspondingly since the two are tight together) in a dynamic fashion. If you turn the MAC key into a long term secret or use it with multiple resource servers then you obviously loose the security benefits. 

All this is documented in Section 5 of http://tools.ietf.org/html/draft-tschofenig-oauth-security-00#section-5

---

From: William Mills <[email-masked]>
Date: Tue, 27 Nov 2012 13:24:41 -0800 (PST)

Responses inline.

>From: Hannes Tschofenig <[email-masked]>
>Cc: Hannes Tschofenig <[email-masked]>; "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>; ext Sergey >Beryozkin <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Tuesday, November 27, 2012 10:54 AM
>Subject: Re: [OAUTH-WG] What needs to be done to complete MAC.
>
>Hi Bill, 
>

Yes.

>With "signed token" do you mean an access token that is signed by the party issuing it? 

No, I meant a token which requires a signature in the transaction to be used.

>Please don't compare bearer tokens with cookies. They are very different. 

For the purposes of this discussion I disagree strongly.  Both are a piece of data transmitted by the client to the server. Cookies can be used for other things but there are certainly authentication cookies in use which have all of the same characteristics as Bearer tokens and in fact could be used interchangeably.

>
>>  Signed token types can be used over plain text channels without the concern about re-use of the token 
>>by a 3rd party.  Replay protection is still needed but that's not in scope for the token mechanism itself.
>
>I guess signed token here means something like MAC where you actually do not sign the token but compute a 
>message digest over some headers of the request. 

Yes, I could have been clearer, signed per access like MAC and OAuth 1.0

>Could you describe your simple use case? For example, is it acceptable for you to use TLS from the client 
>to the authorization server to get the MAC key (and algorithm)? What is your story regarding computing the 
>keyed message digest over the HTTP message: header fields only, body? What about confidentiality protection? 
>What about protecting the actual data (not just the request that contains the access token)?
>

The simple use case is TLS for the authentication and token fetch flows and plain text for everything else.  At the moment for the Flickr case there's no signature over the post body.  The concerns about confidentiality and integrity protection of the post body in bulk traffic are valid.  

>If that's the case and they only use HTTP then they are in violation of the OAuth 1.0a spec. 

Flickr uses TLS to do the OAuth 1.0a flows as per the spec.  All regular application traffic using the tokens for access is HTTP.

>What makes you believe that guys who don't want to use an off-the-shelf library for security will get a 
>custom security solution right.  The performance of TLS is not an issue for mobile devices anymore. It may 
>have been an issue in 2005. 

Because I get told this all the time by mobile developers concerned about latency and battery usage because TLS is marginally more expensive than plain text.  Whether I agree with them or not, it's the feedback I get.

>have to use TLS in their code base. 

Yes.  Authentication and token fetch via SSL are not the issue, it's the bulk traffic.

>The IETF OAuth 1.0a specification requires TLS to be used between the client and the authorization server. 

Sure.  Where did I say differently?

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 28 Nov 2012 14:59:55 +0000

Hi Hannes
> Good that you both raise this point. The refresh token mechanism allows us to request new access tokens (and new keying material correspondingly since the two are tight together) in a dynamic fashi…

IMHO, the MAC key is the property of the individual access token and 
thus does not have to be turned into a long term secret. Re using it 
multiple servers: recall my point about using a given token for the 
specific deployment/case - if the use of MAC tokens is not the right 
thing to do in the advanced deployments - lets have some advice on that.

I'd even compare the use of MAC as compared to other more sophisticated 
tokens to the implicit vs authorization code flow.  The former is 
assumed to be less secure than the latter - nonetheless both are 
supported by the spec - it is about using the right flow for the right 
deployment and being aware of the relevant security threats.

Cheers, Sergey

>> From: "Richer, Justin P."<[email-masked]>
>> To: William Mills<[email-masked]>
>> Cc: "Tschofenig, Hannes (NSN - FI/Espoo)"<[email-masked]>; ext Sergey Beryozkin<[email-masked]>; Hannes Tschofenig<[email-masked]>; "[email-masked]"<[email-masked]>
>>> From: "Tschofenig, Hannes (NSN - FI/Espoo)"<[email-masked]>
>>> To: ext Sergey Beryozkin<[email-masked]>; Hannes Tschofenig<[email-masked]>
>>> Cc: [email-masked]

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 28 Nov 2012 15:11:45 +0000

Hi Hannes
> We had also figured out that there isn't only a single solution that will make everyone happy. But we also don't want to standardize everything comes to our mind: you can see in other areas (e.g.,…

Major thanks for providing the background info and more thoughts on this 
topic...
+1 to the fact it is not realistic to standardize every token type out 
there.

To be honest, as I already indicated, I don't mind if MAC stays the 
draft, we will support it as it's already in the code and will fix the 
things locally at our framework level if the users who will start 
experimenting with it report some issues with the way the signature is 
calculated and such or will want a support for a body hash which I 
believe is optionally supported (?) at the MAC draft level, etc...

I think, with my primitive understanding of the advanced security 
issues, that MAC has few useful properties which can help with the 
simpler cases. But again, from my point of view, it is more about having 
a token type which will be most 'familiar' to 1.0 developers.

May be I'm just repeating myself, sorry :-)

> I am hoping that the conference calls (which I had asked folks to indicate their preference for) will help us to come up with an answer of what the essential requirements are (and hopefully within…
Thanks - will definitely consider once I get a better appreciation of 
OAuth2.0

Cheers, Sergey