Re: [OAUTH-WG] proposal for signatures

In my write-up, I'm saying that if you provide the shared key and you don't care about rotating it, then the verifier can ignore the key_id (the issuer would presumable not include the key_id). Same for public keys - if you upload them out of band and you don't think you'll ever change them, then t

Re: [OAUTH-WG] proposal for signatures

On Tue, Jun 22, 2010 at 2:28 AM, Ben Laurie wrote: > On 22 June 2010 02:14, Dirk Balfanz wrote: > > > > > > On Mon, Jun 21, 2010 at 4:18 AM, Ben Laurie wrote: > >> > >> On 21 June 2010 08:04, Dirk Balfanz wrote: > >> > Hi guys, > >> > I think I owe the list a proposal for signatures. > >> > I

[OAUTH-WG] Extensibility for OAuth?

Hi Eran, Hi all, I briefly browsed through the -08 version of the draft to figure out what could be written about extensibility. Here are a few thoughts: - Client Profiles This is probably the most important item were people will want to write extensions for. Currently, we have the following

Re: [OAUTH-WG] native app support (was: Next draft)

Two points: 1/ I agree that it can be onerous for clients to host web pages. It's not a matter of expense but of complexity. BUT 2/ As we discussed previously in our in-person meeting, this should be handled by a different endpoint, and not be the responsibility for the provider. If Google wi

Re: [OAUTH-WG] proposal for signatures

Hi Dick, interesting point about encrypted payloads. People more cryptographically-inclined than me might want to chime in, but I do seem to remember that there is a "correct" choice among the "encrypt-then-sign" and "sign-then-encrypt" alternatives. A quick search seems to suggest that the latte

Re: [OAUTH-WG] Last call for feedback on -08

Sounds like it's already in for -09 but I'd still like to voice my support for some kind of optional parameter like error_description. I'm working on a draft profiling a specific use of SAML in the assertion grant_type flow (coming soon to this list I hope) and added in an error_detail parameter f

Re: [OAUTH-WG] Last call for feedback on -08

> >  * Handling of unregistered and dynamically-registered clients My discovery draft covers that, but other are free to propose alternatives (before or after I publish my draft). EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/l

[OAUTH-WG] base64url: web-safe encoding; RFC 4648

RFC4648 "The Base16, Base32, and Base64 Data Encodings" defines web-safe base64 (and "normal" base64) . The spec suggests calling it "base64url". The spec explicitly states that: "in some circumstances, the use of padding ("=") in base-encoded da

Re: [OAUTH-WG] Last call for feedback on -08

On Tue, Jun 22, 2010 at 6:24 AM, Justin Richer wrote: > >> I am working on -09 which I hope will be the last major revision of >> the specification. If you were planning on submitting any feedback on >> draft -08 or the simplification proposal from David and me, please do >> so by tomorrow to be i

Re: [OAUTH-WG] native app support (was: Next draft)

On Tue, Jun 22, 2010 at 4:26 PM, Eran Hammer-Lahav wrote: > In that case, I suggest an extension. But I just don't think this needs it. > Why involve the server at all in this? The client should just host a web page > somewhere with the format it wants or the language for the user. > > With $10

Re: [OAUTH-WG] native app support (was: Next draft)

Write the spec then. It should be pretty short. EHL > -Original Message- > From: Marius Scurtescu [mailto:mscurte...@google.com] > Sent: Tuesday, June 22, 2010 4:31 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: native app support (was: Next draft) > > On Tue,

Re: [OAUTH-WG] native app support (was: Next draft)

In that case, I suggest an extension. But I just don't think this needs it. Why involve the server at all in this? The client should just host a web page somewhere with the format it wants or the language for the user. With $10 hosting, every client can host a web page somewhere. EHL > -Or

Re: [OAUTH-WG] proposal for signatures

George: David's example is that keys are managed out of band. When you rotate the key, you tell the other side the new key, then use it. David: I would hope that we would be able to move past the horrible key management that we have today to an architecture using published public keys so that

Re: [OAUTH-WG] native app support (was: Next draft)

On Tue, Jun 22, 2010 at 4:07 PM, Eran Hammer-Lahav wrote: > >> -Original Message- >> From: Marius Scurtescu [mailto:mscurte...@google.com] >> Sent: Tuesday, June 22, 2010 3:35 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: native app support (was: Next draft)

Re: [OAUTH-WG] native app support (was: Next draft)

> -Original Message- > From: Marius Scurtescu [mailto:mscurte...@google.com] > Sent: Tuesday, June 22, 2010 3:35 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: native app support (was: Next draft) > > On Tue, Jun 22, 2010 at 3:14 PM, Eran Hammer-Lahav > wrote:

Re: [OAUTH-WG] native app support (was: Next draft)

On Tue, Jun 22, 2010 at 3:14 PM, Eran Hammer-Lahav wrote: > In OAuth 1.0a, we needed it for the patch. I don't think this needs to be in > the spec because it doesn't help interop. If the server supports such a > scheme, it should document it. It also falls under "previously established > redir

Re: [OAUTH-WG] native app support (was: Next draft)

In OAuth 1.0a, we needed it for the patch. I don't think this needs to be in the spec because it doesn't help interop. If the server supports such a scheme, it should document it. It also falls under "previously established redirection URI" which happens to point at the server. EHL > -Orig

Re: [OAUTH-WG] Draft -07 (major rewrite)

You are a bit behind. -08 added it back as grant_type which works better with the current explanation. EHL From: Dick Hardt [mailto:dick.ha...@gmail.com] Sent: Tuesday, June 22, 2010 1:29 PM To: Brian Eaton Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Draft -07 (major

Re: [OAUTH-WG] Last call for feedback on -08

It was proposed as part of the device or username and password flow IIRC. Google has something like that when captcha breaks. EHL > -Original Message- > From: David Recordon [mailto:record...@gmail.com] > Sent: Tuesday, June 22, 2010 1:47 PM > To: Eran Hammer-Lahav > Cc: Marius Scurtescu

Re: [OAUTH-WG] proposal for signatures

The only additional value might be during "key rotation". If key_id is removed, then both (or n) have to be checked. Probably not a huge issue. Thanks, George On 6/22/10 4:45 PM, David Recordon wrote: Hey Dick, in answering my questions you made my point. If keys are managed out of band -- as

Re: [OAUTH-WG] Last call for feedback on -08

If we have both error_code and error_description, why is an error_uri needed? (I'm not finding anything when I search the list for 'error_uri'.) On Tue, Jun 22, 2010 at 1:05 PM, Eran Hammer-Lahav wrote: > There was also a suggestion by Brian to add an error_uri for additional > information. > >

Re: [OAUTH-WG] proposal for signatures

Hey Dick, in answering my questions you made my point. If keys are managed out of band – as is done in OAuth 1.0 and what was done in the OAuth 2.0 Core spec until signatures were extracted – then having a key id is not needed. I certainly understand what they're used for, but don't find them relev

Re: [OAUTH-WG] Draft -07 (major rewrite)

Per an earlier comment, "type" might not be the best name for the parameter. Perhaps "method" might work and adds a clear extension point for other types of calls? On Tue, Jun 22, 2010 at 1:22 PM, Dick Hardt wrote: > One of the modifications I concluded to do to WRAP was to add in the type > par

Re: [OAUTH-WG] Draft -07 (major rewrite)

One of the modifications I concluded to do to WRAP was to add in the type parameter. I was happy to see if in David's draft. Even though redundant in some ways, it make it very clear to both the client and server what is intended. +1 for putting it back in. On Mon, Jun 14, 2010 at 11:23 AM, Bria

Re: [OAUTH-WG] Last call for feedback on -08

There was also a suggestion by Brian to add an error_uri for additional information. I'm happy to include all three. EHL > -Original Message- > From: Marius Scurtescu [mailto:mscurte...@google.com] > Sent: Tuesday, June 22, 2010 1:00 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf

Re: [OAUTH-WG] native app support (was: Next draft)

On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu wrote: > In order to properly support native applications I suggest the > following changes: > [...] > 2. optional redirect_uri (default result page) > > Some native apps do not have a redirect_uri, as a result two things are > needed: > > 2.1 Eit

Re: [OAUTH-WG] Last call for feedback on -08

There was a suggestion to expand the 'error' parameter to two different parameters: - error_code - well defined list of error codes - error_description - authz server specific free form error description (for logging and troubleshooting) Not sure if you considered this. Marius On Mon, Jun 21,

Re: [OAUTH-WG] proposal for signatures

David key_ids are used when you need to identify which key to use of all the keys you might have. If you are doing discovery of document that is bound to the identifier of the signer, this is useful. Since OAuth 1.0 did not have discovery and required an out of band key management process, key_ids

Re: [OAUTH-WG] proposal for signatures

All of the OAuth 1.0 implementations which I'm aware of either have the server provide a shared secret to the client or the client upload their public key to the server. In the case of the server providing a shared secret to the client, what would the value of key_id be? In the case of a client u

Re: [OAUTH-WG] proposal for signatures

I could imagine an architecture striving to be efficient, scalable, distributed and secure where there are hundreds of servers each with a unique private key baked into each server. All the public keys would be in one file. Having a key id would help debugging as well as the signer is clearly indi

Re: [OAUTH-WG] proposal for signatures

> Aside/my $.02: This is a key issue which Salmon+Magic Signatures > evades by essentially treating the HTTP request (the method, URL, > headers, etc.) as advisory/transport hints, to be ignored when reading > the data, and making sure the protocol works even if the data is sent > via carrier pige

Re: [OAUTH-WG] proposal for signatures

> If a server needs to verify, it can literally iterate over all of the keys > associated with the client until it finds the right one. Depends on how the server stored the keys, this can be a very expensive operation w/o a key_id to match/index on -Original Message- From: oauth-boun...

Re: [OAUTH-WG] proposal for signatures

On Tue, Jun 22, 2010 at 2:36 AM, Ben Laurie wrote: > On 22 June 2010 07:03, David Recordon wrote: > > Thanks for writing this. A few questions... > > > > Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` > > instead at least for OAuth? > > > > Can we write out algorithm instead

Re: [OAUTH-WG] proposal for signatures

Having a key ID is an optimization. If you're using public key signatures is having to do potentially 3x the signatures going to be a problem? > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] > On Behalf Of Brian Eaton > Sent: Tuesday, June 22, 2010

Re: [OAUTH-WG] proposal for signatures

On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt wrote: >> Thanks for writing this. A few questions... >> >> Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` >> instead at least for OAuth? > > it is the ID of the key, not the client -- used to rollover keys I don't think key id is n

Re: [OAUTH-WG] proposal for signatures

On 2010-06-21, at 11:03 PM, David Recordon wrote: > Thanks for writing this. A few questions... > > Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` > instead at least for OAuth? it is the ID of the key, not the client -- used to rollover keys > Does "websafe-base64-encoded"

Re: [OAUTH-WG] Last call for feedback on -08

> I am working on -09 which I hope will be the last major revision of > the specification. If you were planning on submitting any feedback on > draft -08 or the simplification proposal from David and me, please do > so by tomorrow to be included in the next draft. I am mostly looking for the ext

Re: [OAUTH-WG] proposal for signatures

On 22 June 2010 07:03, David Recordon wrote: > Thanks for writing this. A few questions... > > Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` > instead at least for OAuth? > > Can we write out algorithm instead of `alg`? > > How do you generate the body hash? > > Does "websafe

Re: [OAUTH-WG] proposal for signatures

On 22 June 2010 02:40, Manger, James H wrote: > Nat and Ben, > > > In addition to Ben's questions, I have another. For X.509, you seem to > be using DER. How do you express the entire certificate chain using > DER? > (With PEM, you can just concatenate ... ) > >>> > >>> With DE

Re: [OAUTH-WG] proposal for signatures

On 22 June 2010 02:14, Dirk Balfanz wrote: > > > On Mon, Jun 21, 2010 at 4:18 AM, Ben Laurie wrote: >> >> On 21 June 2010 08:04, Dirk Balfanz wrote: >> > Hi guys, >> > I think I owe the list a proposal for signatures. >> > I wrote something down that liberally borrows ideas from Magic >> > Signa

[OAUTH-WG] Minor corrections to -08

Hello, In section 1.4., “exchaning” should be “exchanging.” In section 1.4.3., “user-agnet” should be “user-agent.” In section 4., “support addition mechanisms” should be “support additional mechanisms.” And, as already mentioned on the list, “access grand type” in section 4 should be “access

Re: [OAUTH-WG] proposal for signatures

btw, I wrote a very naive PHP sample. http://gist.github.com/448164 On Mon, Jun 21, 2010 at 11:03 PM, David Recordon wrote: > Thanks for writing this. A few questions... > > Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` > instead at least for OAuth? > > Can we write out algo

Re: [OAUTH-WG] proposal for signatures

Thanks for writing this. A few questions... Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` instead at least for OAuth? Can we write out algorithm instead of `alg`? How do you generate the body hash? Does "websafe-base64-encoded" mean that I can't just blindly use my languag

Re: [OAUTH-WG] OAuth discovery draft?

Yes, it's on my desk and not yet ready, but I am working on one. It includes your sites proposal among other things. I am trying to get the core spec stable this week and focus on that next. EHL > -Original Message- > From: Manger, James H > Sent: Monday, June 21, 2010 8:03 PM >