I agree that is the cleanest.

John B.
On 2011-10-14, at 3:18 PM, Mike Jones wrote:

> I think that William Mills already gave the best answer to the extensibility 
> question when he wrote:
> "I think removing the auth-param usage is workable.  Then if we need 
> extensibility defining a new scheme can do that.  It's a bit more work that 
> way if needed, but it's clean."
> 
>                               Best wishes,
>                               -- Mike
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of 
> Hannes Tschofenig
> Sent: Friday, October 14, 2011 11:14 AM
> To: Bob Van Zant
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed 
> Resolutions
> 
> Hi Bob, 
> 
> the question is only how to provide extensibility then. You are then 
> essentially forced to know, because of pre-arrangements, what the content of 
> the blob is going to be. 
> 
> Is that also fine for you? 
> 
> On Oct 14, 2011, at 7:04 PM, Bob Van Zant wrote:
> 
>> I'm in favor of removing the auth param option. It seems that half the 
>> point of the Bearer token is to have a very simple way of passing 
>> around opaque tokens.
>> 
>> If there are reasons for building a more feature-ful token with cool 
>> parameters then let's bring about a new token type. For now I like the 
>> brain dead simple Bearer:
>> 
>>   credentials = "Bearer" 1*SP b64token
>> 
>> -Bob
> 
> Ciao
> Hannes
> 
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to