Re: [OAUTH-WG] Defining a maximum token length?

Along those lines, here's an access token (SWT w/o URL encoding) that has some role and attribute data. I think it is representative of how customers are using the OAuth WRAP implementation in AppFabric. Role=user,superuser,administrator&Action=create,retrieve,update,delete&CustomerID=123456789&

Re: [OAUTH-WG] Defining a maximum token length?

On Mar 9, 2010, at 6:50 PM, David Recordon wrote: > Ideally we'd limit the length of access and refresh tokens as well as > client keys and secrets to no more than 255 characters (a one byte > varchar in MySQL). Is this an issue for anyone? Yes. Why would we want to encode such a specific impl

Re: [OAUTH-WG] Defining a maximum token length?

On 03/10/2010 04:42 PM, John Kemp wrote: > One reason I can imagine is to make it possible to encode information into > the token itself so that the token can be "self-contained" (mentioned also by > others on this list). > Though thats an interesting option, compatibility of implementations

Re: [OAUTH-WG] Defining a maximum token length?

On Mar 10, 2010, at 11:16 AM, Moritz Maisel wrote: > On 03/10/2010 04:42 PM, John Kemp wrote: >> One reason I can imagine is to make it possible to encode information into >> the token itself so that the token can be "self-contained" (mentioned also >> by others on this list). >> > > Though t

Re: [OAUTH-WG] [WRAP] Username and Password Profile

+1 I'd like to keep the existing username/password profile as it currently is, with the understanding that Service Providers may add additional proprietary parameters and secret sauce to authenticate the client. Allen On 3/9/10 9:32 PM, "Brian Eaton" wrote: > On Tue, Mar 9, 2010 at 12:02 PM,

Re: [OAUTH-WG] [WRAP] Username and Password Profile

+1 On 2010-03-10, at 8:51 AM, Allen Tom wrote: > +1 > > I'd like to keep the existing username/password profile as it currently is, > with the understanding that Service Providers may add additional proprietary > parameters and secret sauce to authenticate the client. > > Allen > > > On 3/9/1

Re: [OAUTH-WG] [WRAP] Username and Password Profile

That seems reasonable to me. We should make sure to distill this discussion into a "security considerations" section for that profile. On Mar 10, 2010, at 8:55 AM, Dick Hardt wrote: > +1 > > On 2010-03-10, at 8:51 AM, Allen Tom wrote: > >> +1 >> >> I'd like to keep the existing username/passw

Re: [OAUTH-WG] Defining a maximum token length?

Standards have size limits to overcome operational issues all the time. For an extreme example look at the backflips that MIME goes through to insure that mail can be delivered by even the most hostile relay. (Including systems using EBCDIC, and systems that mangle payloads!) If there are no

Re: [OAUTH-WG] Anaheim agenda, v0.1

On 3/4/10 6:46 PM, Dick Hardt wrote: > I could have some commentary on the mixed approach as well. For sure. I think we'll have a lively discussion. :) I'll upload the draft agenda soon in a more official capacity... Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/

[OAUTH-WG] draft agenda

I've uploaded a draft agenda for our meeting at IETF 77: http://www.ietf.org/proceedings/10mar/agenda/oauth.txt Agenda bashing is welcome on the list. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___

Re: [OAUTH-WG] Defining a maximum token length?

On Mar 10, 2010, at 3:47 PM, Paul Lindner wrote: > Standards have size limits to overcome operational issues all the time. Standards usually standardize on the things necessary for interoperability, and token size isn't a necessity for interoperability unless we make it one. No-one has explaine

Re: [OAUTH-WG] Defining a maximum token length?

RFC 2822 provides an apropos example in sections 2.1.1: There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding

[OAUTH-WG] Thinking about our secrets for signatures

Has anyone else put some thought into what secrets are used within the signature algorithm for OAuth 2.0? OAuth 1.0 combines the client secret and the token secret with an ampersand in the middle. WRAP doesn't support signatures and relies on the fact that access tokens should remain secret via S