Re: An OAuth OpenID Extension
Joseph, Any help you could provide to flesh out (or heavily modify) these specs would be most appreciated. Thanks, John Ehn extremeswank.com On 10/22/07, Joseph Holsten <[EMAIL PROTECTED]> wrote: > > Wow, these are neat. Thanks for the links david, and especially the > work john! > > OK, so the Inline Auth use case seems like a straightforward case for > OAuth: resource url => identifier, user auth url => delegate. > Successfully accessing the resource after negotiation would imply > that the user still trusts the RP. Seems like low hanging fruit. > Also, gets the benefit of single sign off! > > I'm a little unsure about the best way for the Trusted Auth use case. > This seems quite good, but a diagram of an oauth solution to the > problem was on the mailing list not long ago. Same as the official > diagram, but with a third column showing interactions between the > "Consumer Directs User to Service Provider" and "Service Provider > Directs User to Consumer" steps. I looked for half an hour, found > nothing, but I'm not crazy really! Anyway, it would be nice to > compare perspectives first. > > But if I remember correctly, the oauth proposal only allowed the > "Service Provider"/"Destination Consumer" to revoke resource access, > while openid trusted auth gives that right to the OP. Greater > overhead versus greater user control. > > So who's interested in fleshing out these recommendations into specs? > > http:/ joseph holsten .com > > > On 02007:10:22, at 3:54CDT, David Recordon wrote: > > > Hey all, > > I know John did some work in September (http://extremeswank.com/ > > openid_trusted_auth.html and http://extremeswank.com/ > > openid_inline_auth.html). Both solve extremely important use-cases > > and are becoming increasingly discussed especially with the advent of > > OAuth. I'd really like to see how we can work to write an extension > > to OpenID Authentication where the OpenID Provider is also the one > > handling OAuth credentials. This would be useful in the inline > > authentication use case as well as if we move to a deployment > > scenario where the OAuth Provider is checking with the user's OpenID > > Provider to verify OAuth signatures. Overtime I also think moving > > OpenID to the OAuth signature mechanism would be beneficial, but I > > think that is a longer conversation. > > > > --David > > > > ___ > > specs mailing list > > specs@openid.net > > http://openid.net/mailman/listinfo/specs > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: An OAuth OpenID Extension
Wow, these are neat. Thanks for the links david, and especially the work john! OK, so the Inline Auth use case seems like a straightforward case for OAuth: resource url => identifier, user auth url => delegate. Successfully accessing the resource after negotiation would imply that the user still trusts the RP. Seems like low hanging fruit. Also, gets the benefit of single sign off! I'm a little unsure about the best way for the Trusted Auth use case. This seems quite good, but a diagram of an oauth solution to the problem was on the mailing list not long ago. Same as the official diagram, but with a third column showing interactions between the "Consumer Directs User to Service Provider" and "Service Provider Directs User to Consumer" steps. I looked for half an hour, found nothing, but I'm not crazy really! Anyway, it would be nice to compare perspectives first. But if I remember correctly, the oauth proposal only allowed the "Service Provider"/"Destination Consumer" to revoke resource access, while openid trusted auth gives that right to the OP. Greater overhead versus greater user control. So who's interested in fleshing out these recommendations into specs? http:/ joseph holsten .com On 02007:10:22, at 3:54CDT, David Recordon wrote: > Hey all, > I know John did some work in September (http://extremeswank.com/ > openid_trusted_auth.html and http://extremeswank.com/ > openid_inline_auth.html). Both solve extremely important use-cases > and are becoming increasingly discussed especially with the advent of > OAuth. I'd really like to see how we can work to write an extension > to OpenID Authentication where the OpenID Provider is also the one > handling OAuth credentials. This would be useful in the inline > authentication use case as well as if we move to a deployment > scenario where the OAuth Provider is checking with the user's OpenID > Provider to verify OAuth signatures. Overtime I also think moving > OpenID to the OAuth signature mechanism would be beneficial, but I > think that is a longer conversation. > > --David > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
An OAuth OpenID Extension
Hey all, I know John did some work in September (http://extremeswank.com/ openid_trusted_auth.html and http://extremeswank.com/ openid_inline_auth.html). Both solve extremely important use-cases and are becoming increasingly discussed especially with the advent of OAuth. I'd really like to see how we can work to write an extension to OpenID Authentication where the OpenID Provider is also the one handling OAuth credentials. This would be useful in the inline authentication use case as well as if we move to a deployment scenario where the OAuth Provider is checking with the user's OpenID Provider to verify OAuth signatures. Overtime I also think moving OpenID to the OAuth signature mechanism would be beneficial, but I think that is a longer conversation. --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs