Brian,
OAuth bearer tokens are to a large degree glorified cookies. Cookies have been
massively deployed in the wild with their own variety of a "sites" parameter
("domain", "path" and "secure" parameters).
The biggest different between cookies and OAuth tokens today is that a client
app needs a huge dollop of service-specific knowledge to use OAuth.
I'd argue that the cookie experience counts as determining what a bearer token
system needs to work at Internet scale.
P.S. I have a hazy memory that Google did use redirects with an OAuth 1 API
that caused some clients to break. I think some re-signed requests, and others
didn't. That might be a case where a "sites" parameter would have made the
right approach obvious (unless it was just an escaping issue). Anyone have a
better memory?
--
James Manger
-----Original Message-----
From: Brian Eaton [mailto:[email protected]]
Sent: Tuesday, 11 May 2010 9:11 AM
To: Manger, James H
Cc: OAuth WG ([email protected])
Subject: Re: [OAUTH-WG] sites with wildcard
...
As I've said in a few other e-mail threads, I think it would be a
serious mistake to publish a standard that doesn't reflect things that
are already deployed in the wild and are well-understood.
If people want to see systems that automatically determines scopes and
reuses tokens, I think they should go and build those systems. Then
come back to the community with explanations of what they did, and why
other people should adopt it.
Cheers,
Brian
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
