Trolls have special diets properly balanced for their information needs. Please, for their health and yours, don't feed the trolls. -- http://josephholsten.com
On May 19, 2010, at 3:11 AM, Pid wrote: > On 19/05/2010 09:51, Santosh Rajan wrote: >> [snip] > > I *am* new around here and I'm trying to get up to speed with the state > of play. I would find it easier to comprehend the suggestions being > discussed if there was slightly less background noise. > > A community supporting a mature standard or product need not offer new > things regularly as long as it can support the inquiries of new members. > > I think it would be unusual to churn out new specs constantly just to > keep new community members interested. This is not an environment > that's comparable to an online shop. > > > $0.02 > > > p > > > >> On Wed, May 19, 2010 at 1:50 PM, David Recordon <[email protected] >> <mailto:[email protected]>> wrote: >> >> Replying with "bullshit" isn't going to welcome anyone new into this >> community. Please stop doing this; you've been asked many times. >> >> Yes, we should increase the involvement of browser vendors and it's >> great seeing the work that's happening around FireFox. I plan to >> track down that team tomorrow and get a better understanding of what >> browser-based APIs they're proposing and what information websites >> need to advertise to browsers. >> >> --David >> >> >> On Wed, May 19, 2010 at 1:12 AM, Santosh Rajan <[email protected] >> <mailto:[email protected]>> wrote: >> >> HA! BullShit! >> >> [snip] >> >> On Wed, May 19, 2010 at 1:25 PM, David Recordon >> <[email protected] <mailto:[email protected]>> wrote: >> >> Coming out of some conversations at IIW today I've made some >> changes to the proposal. Patch is attached, but they are: >> - Allow passing in `user_id` as a hint when not using >> immediate mode in the request. >> - Continue to allow users to enter URLs, email addresses, >> and click buttons but the returned user identifier must be a >> HTTPS URI. >> - Include the expiration time within the signature. >> - Clarify how you verify if the token endpoint is >> authoritative for a given user identifier. >> - Simplify discovery by removing LRDD and using host-meta >> to determine the server token endpoint on a per domain (or >> sub-domain) basis. We're having a hard time finding use >> cases of running multiple different OpenID servers per domain. >> - Remove the separate user info API endpoint and instead >> make the user identifiers a protected resource. Fetch the >> user identifier with an access token and it returns basic >> profile information as well as if the access token was >> issued by that specific user. >> >> Thanks for all of the feedback and support both virtually >> and in person! I'm planning to move this proposal into >> GitHub next week (and work with Eran to actually format it >> like a spec) so that changes are easier to keep track of. >> >> --David >> >> _______________________________________________ >> specs mailing list >> [email protected] <mailto:[email protected]> >> http://lists.openid.net/mailman/listinfo/openid-specs >> >> >> >> >> -- >> http://hi.im/santosh >> >> >> >> >> >> >> -- >> http://hi.im/santosh >> >> >> >> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs > > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
