Re: [OAUTH-WG] proposal for signatures

Hi Dirk Responding to this now that you are back. From: http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html (which is the whitepaper talking contrasting "encrypt-then-sign" and "sign-then-encrypt") The simple solution seems to be to include both sender and recipient in th

Re: [OAUTH-WG] proposal for signatures

I don't understand. You are Allowed time off spec work during vacation? Hmm. (-: EHL On Jul 9, 2010, at 16:39, Dirk Balfanz mailto:balf...@google.com>> wrote: On Wed, Jul 7, 2010 at 7:49 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrot

Re: [OAUTH-WG] proposal for signatures

On Wed, Jul 7, 2010 at 7:49 PM, Eran Hammer-Lahav wrote: > Can we get an updated document based on the feedback received? > Sure - I just got back from my vacation. I'll read through the thread and update the docs. Cheers, Dirk. > EHL > > > On 6/21/10 12:04 AM, "Dirk Balfanz" wrote: > >

Re: [OAUTH-WG] assertion profile changes

To directly address the 3 issues in Brian C's summary: 1) I haven't seen any strong use-cases for the issuing of refresh tokens either, but we do find the SHOULD NOT language to be strong enough. 2) We support client_id being optional, and will have need for it.No support for mandatory, nor

Re: [OAUTH-WG] assertion profile changes

On 7/8/10 3:49 PM, "Brian Eaton" wrote: Nice summary, thanks Brian! I think there is a third issue as well, i.e. what the use case for client_id actually is. I think Chuck's use case has client_id used to disambiguate the purpose of the SAML assertion. We have a similar use case, both for

Re: [OAUTH-WG] In dire need of the device flow

Arnout, The draft on the use cases that Igor mentions reflects the cases that had been discussed before the publication of the OAuth2.0 -06 version. It does include the device flow. Then there was a proposal to move the device flow from the core specification to a separate draft (see http://www

Re: [OAUTH-WG] Versioning

See comments bellow... On Fri, Jul 9, 2010 at 4:27 AM, Stefanie Dronia wrote: > Hallo Marius, > > thanks for your statement. > Your idea of a migration flow is quite good and necessary. > > But I still doubt, if the work and effort should be investigated to spare > the user from some interaction

Re: [OAUTH-WG] The meaning of scope

Hello, Even though I realize that the small open-source lib developer voice might not carry much weight, I would to make a small contribution to this thread, presenting the WG with the mechanics we currently use to support scopes in our soon to release -09 Ruby provider lib: 1) a provider reg

Re: [OAUTH-WG] Versioning

Hallo Marius, thanks for your statement. Your idea of a migration flow is quite good and necessary. But I still doubt, if the work and effort should be investigated to spare the user from some interaction (authentication and user consent). Latest he will be asked for his consent at the time, th

Re: [OAUTH-WG] assertion profile changes

Agree, good summary Brian C I still haven't seen the use case for refresh tokens with assertion flow! We can control that server side but it is easier to just implement the spec as is. It seems insecure granting a refresh token with potentially longer life than the assertion. Do people intent on