<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Links for those that haven't looked yet.<div><br></div><div><blockquote type="cite" style="font-family: monospace; "><a href="https://browserid.org/">https://browserid.org/</a><br></blockquote><blockquote type="cite" style="font-family: monospace; "><a href="http://arstechnica.com/web/news/2011/07/mozillas-browserid-aims-to-simplify-authentication-on-the-web.ars">http://arstechnica.com/web/news/2011/07/mozillas-browserid-aims-to-simplify-authentication-on-the-web.ars</a></blockquote><br></div><div>They are using asymmetrically signed JWT with an introspection endpoint.</div><div><br></div><div>There are limitations on attributes, identifiers and other serious issues with what Mozzila is proposing.</div><div><br></div><div>Though it is relatively close to what Nat and I were thinking with asymmetrically signed id_tokens, and a introspection endpoint.</div><div><br></div><div>In some ways our flow would be simpler if the id_tokens were always asymmetrically signed and anyone not supporting that uses the introspection endpoint.</div><div><br></div><div>If the RP doesn't understand asymmetric signatures it just throws to the introspection endpoint. </div><div>The big advantage is for smart clients. They would not need to manage shared secrets to validate tokens.</div><div><br></div><div>For a smart client I suppose that you could let it generate it's own access tokens if those access tokens are JWT and they wrap a JWT containing the client's public key and some scope constraints etc. In principal that could lower the IdP's authorization load, however I don't know if it would be worth it.</div><div><br></div><div>Just some things to think about.</div><div><br></div><div>John B.</div><div><br></div></body></html>