Yahoo is currently testing SREG, and we'd like to see the 1.1 SREG draft
updated to clarify any ambiguities before we're done testing. We'd also
like to see the schema updated to include the user's profile pic.
We decided to build support for SREG before AX because SREG seems to be
more widely
On 2-Dec-08, at 3:41 PM, Allen Tom wrote:
We decided to build support for SREG before AX because SREG seems to
be
more widely used, and also because SREG allows the RP to pass the
url to
its privacy policy in the request. Strangely, AX does not have an
interface for the RP to pass its
Dirk Balfanz wrote:
On Tue, Nov 25, 2008 at 7:17 PM, Allen Tom [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
In Section 10, and perhaps also in Section 12, the spec should
mention that because the hybrid protocol does not have a request
token secret, and because the user is
Interesting point, and probably worth adding to a security portion of the spec.
I would say though, that is bad security hygiene to share the same
consumer key between your web and desktop apps. Since we can't vouch
for consumer keys stored in desktop apps anyway, I would volunteer
that the most
It's definitely bad hygiene for developers to leak their secrets to the
browser, or to reuse their website's CK for a downloadable client
application, and we're doing all that we can to encourage good hygiene.
For the time being, we prefer to require CKs for client applications
(even if they
On Tue, Dec 2, 2008 at 4:58 PM, Allen Tom [EMAIL PROTECTED] wrote:
It's definitely bad hygiene for developers to leak their secrets to the
browser, or to reuse their website's CK for a downloadable client
application, and we're doing all that we can to encourage good hygiene.
For the time
Allen Tom wrote:
For the time being, we prefer to require CKs for client applications
(even if they can't be verified) mostly to make it easy for us to pull
the plug on specific applications if they are discovered to be severely
buggy or dangerous. We'd also like to require
